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From  the  Sponsor 


Are  Your  Communications  Skills  Advancing? 


Since  humans  first  walked  the  earth,  we  have  had  a  continuing  and  unending  desire  to 
communicate  and  interact.  Early  cave  dwellers  used  simple  grunting,  then  developed 
crude  cave  paintings  to  convey  thoughts  and  events.  The  Roman  Empire  developed  a  mas¬ 
sive  road  system,  a  type  of  communications  system,  which  had  a  major  impact  on  cultur¬ 
al  development  and  commerce.  In  1436,  German  inventor  Johannes  Gutenberg  developed 
the  printing  press,  revolutionizing  human  communications.  In  the  20th  century,  mass  pro¬ 
duction  of  paper  news  media  became  commonplace,  silent  pictures  led  to  talking  pictures, 
and  radio  and  telephone  connected  people  instantaneously.  By  the  1990s,  personal  computers  and 
the  Internet  became  the  most  significant  communications  medium  in  human  development  history. 
Today,  we  communicate  and  transfer  knowledge  all  over  the  world  in  a  matter  of  seconds  through 
fiber  optic  networks,  satellite  communications,  software,  and  wireless  networks.  Who  knows  what 
the  future  holds? 

Regardless,  human  communication  boils  down  to  basic  interaction  between  people:  transmit¬ 
ting  and  receiving  a  message,  which  is  incredibly  complex.  Many  influences  come  into  play  Did  the 
speaker  use  the  correct  words?  Did  the  listener  understand  the  words?  What  were  the  tones  and 
inflection  used  for  emphasis,  and  what  was  the  person’s  body  language?  And  if  communicating  in 
writing,  we  remove  the  added  dimensions  of  extra  words:  tone,  inflection,  and  body  language.  An 
effective  communicator  must  craft  and  polish  his  or  her  communications  skills  over  time. 

The  question  is,  how  well  are  we  communicating,  and  are  we  perfecting  our  skills  daily?  I  hope 
we  can  all  improve  our  communications  skills  by  studying  this  month’s  theme  articles.  Doing  so, 
maybe  we  can  move  a  few  steps  farther  away  from  using  grunting  and  crude  painting  of  symbol¬ 
ogy  on  the  walls  in  our  day-to-day  interactions  with  each  other. 


Bob  Zwitch 

Warner  Robins  Air  Logistics  Center  Co-Sponsor 


From  the  Publisher 

Communications:  Continuous  Improvement  Required 

All  of  our  readers  can  relate  to  this  month’s  theme:  communication.  We  communi¬ 
cate  in  all  facets  of  our  lives  with  workplace  communications  bringing  some  of 
our  biggest  challenges.  We  are  very  careful  in  what  we  say  or  don’t  say.  We  can  be  quick 
to  blame  customers  on  bad  requirements  or  communicate  poorly  when  defending  proj¬ 
ect  slips,  cost  overruns,  or  defects  in  our  work.  Communication  is  a  skill  that  requires 
continuous  improvement.  I  strive  to  communicate  with  trust,  honesty,  integrity,  and  sin¬ 
cerity,  and  to  listen  openly.  The  ever-changing  dynamics  of  project  work,  though,  make 
this  easier  said  than  done.  Fortunately,  I  am  part  of  a  staff  that  communicates  effectively;  I  know 
firsthand  how  this  can  bond  a  team  togetiier  and  help  them  prosper  in  a  safe  and  comfortable 
work  environment.  An  effective  team  producing  a  quality  product  is  the  best  result  of  all. 

This  month’s  issue  focuses  on  improving  communication  skills  among  team  members.  It  is 
filled  with  excellent  advice  and  lessons  learned  from  implementing  project  charters,  to  under¬ 
standing  change  management,  to  creating  safe  and  productive  meeting  and  work  environments, 
to  improving  communications  through  process  tools,  to  improving  e-mail  communications. 

Also,  we  are  busy  preparing  for  another  year  at  CROSSTALK.  Please  note  our  2006  co¬ 
sponsor  team  lineup  (see  page  4)  and  CROSSTALK  Editorial  Board  (see  page  5).  A  special 
thanks  to  everyone  behind  the  scenes  who  helps  with  CROSSTALK’S  continuing  journey  as  an 
informational  and  educational  source  for  systems  and  software  professionals.  I  hope  your  year 
is  off  to  a  great  start. 

Tracy  Stauder 
Publisher 
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Policies,  News,  and  Updates 


Announcing  Crosstalk’s  Co-Sponsor  Team  for  2006 


Tracy  Stauder 
Crosstalk 


I  am  excited  and  pleased  to  announce  the  five  co-sponsors  of  CROSSTALK,  The  Journal  of  Defense  Software  Engineering 
for  2006.  The  U.S.  Department  of  Homeland  Security  and  the  Naval  Air  Systems  Command  have  joined  with  our  former 
2005  co-sponsors,  the  three  U.S.  Air  Force  Air  Logistics  Centers’  Software  Maintenance  Groups,  to  become  the 
CROSSTALK  Co-Sponsor  Team  for  2006.  On  behalf  of  our  readers  and  staff,  I  welcome  our  new  co-sponsors  and  offer  a 
special  thanks  to  our  former  co-sponsors  for  their  continued  support.  Co-sponsor  team  members  are  identified  below  with  a  descrip¬ 
tion  of  their  organisation.  Hook  for  their  contributions  each  month  in  our  From  the  Sponsor  column  found  on  page  3.  Their 
organisations  will  also  be  highlighted  on  the  back  cover  of  each  CROSSTALK. 


Kevin  Stamey,  76  SMXG  Director 

The  76th  Software  Maintenance  Group  at  the 
Oklahoma  City- Air  Logistics  Center  is  a  leader  in 
the  avionics  software  industry  that  understands 
the  importance  of  total  system  integration.  The 
center  has  a  proven  track  record  of  producing 
software  on  time,  on  budget,  and  defect-free.  Its 
staff  of  software  professionals  and  industry  partners  provides  the 
expertise,  software,  weapons,  interface,  and  aircraft  systems  that 
are  fully  integrated  to  ensure  dependable  war- winning  capabilities. 
The  center’s  areas  of  expertise  include  navigation,  radar,  weapons 
and  system  integration,  systems  engineering,  operational  flight 
software,  automatic  test  equipment,  and  more.  See  <www.bringit 
totinker.com>  for  more  information. 


Randy  Hill,  309  SMXG  Director 

The  309th  Software  Maintenance  Group  at  the 
Ogden-Air  Logistics  Center  is  a  recognized 
world  leader  in  cradle-to-grave  systems  support, 
encompassing  hardware  engineering,  software 
engineering,  systems  engineering,  data  manage¬ 
ment,  consulting,  and  much  more.  The  division 
is  a  Software  Engineering  Institute  Software  Capability  Maturity 
Model®  (CMM®)  Level  5  Organization  with  Team  Software 
Process™  engineers.  Currently  the  division  is  transitioning  to 
CMM  Integration™,  which  integrates  systems  engineering  prac¬ 
tices  with  software  engineering  processes.  This  model  more 
closely  matches  the  complex  hardware,  software,  and  systems 
products  and  capabilities  representative  of  the  organization’s 
breadth  of  products  and  services.  See  <www.mas.hill.af.mil>  for 
more  information. 


Bob  Zwitch,  402  SMXG  Deputy  Director 

The  402d  Software  Maintenance  Group  at  the 
Warner  Robins-Air  Logistics  Center  provides 
combat-ready  weapon  systems,  equipment,  serv¬ 
ices,  and  support  personnel  for  the  U.S.  Air 
Force.  The  center  is  a  leader  in  systems  engi¬ 
neering;  reliability,  maintainability,  and  availabili¬ 
ty  engineering;  safety  engineering;  human  factors  engineering; 


®  Capability  Maturity  Model  and  CMM  are  registered  in  the  U.S.  Patent  and  Trademark 
Office  by  Carnegie  Mellon  University. 

SM  CMM  Integration  and  Team  Software  Process  are  service  marks  of  Carnegie  Mellon 
University. 


advanced  design  and  manufacturing  engineering;  and  logistics 
engineering  support.  The  center  has  worldwide  management  and 
engineering  responsibility  for  the  repair,  modification  and  over¬ 
haul  of  the  F-15  Eagle,  C-130  Hercules,  C-141  Starlifter,  C-5 
cargo  aircraft,  U-2  surveillance  aircraft,  all  Air  Force  missiles,  all 
Air  Force  helicopters,  and  more.  See  <https://www.mil. 
robins.af.mil>  for  more  information. 


Joe  Jarzombek,  Department  of  Homeland 
Security  -  Director  of  Software  Assurance 

The  Department  of  Homeland  Security  (DHS) 
National  Cyber  Security  Division  serves  as  a 
focal  point  for  software  assurance,  as  part  of 
ensuring  the  security  of  cyberspace,  and  works 
closely  with  the  private  sector,  academia,  other 
government  agencies,  and  international  allies  to  improve  soft¬ 
ware  development  and  acquisition  processes  that  will  lead  to  bet¬ 
ter  quality  and  more  secure  software.  DHS  provides  the  public- 
private  framework  for  shifting  tire  paradigm  from  patch  manage¬ 
ment  to  software  assurance.  For  more  information  see  <www. 
us-cert.gov>  and  <https://buildsecurityin.us-cert.  gov/portal>. 

Terry  Clark,  NAVAIR,  Systems  Engineering 
Department  -  Director,  Software  Engineering 

The  Naval  Air  Systems  Command  (NAVAIR) 
provides  the  cost-wise  readiness  and  dominant 
maritime  combat  power  to  make  a  great 
Navy/Marine  Corps  team  better.  NAVAIR  bal¬ 
ances  current  and  future  readiness  to  ensure  that 
naval  aviators  are  provided  with  the  right  products  to  fight  the 
global  war  on  terrorism  and  other  potential  future  conflicts.  The 
NAVAIR  team,  in  partnership  with  industry,  is  committed  to 
serving  the  nation  and  the  Navy  by  developing,  acquiring,  and 
supporting  naval  aeronautical  and  related  technology  systems 
with  which  the  operating  forces,  in  support  of  the  unified  com¬ 
manders  and  our  allies,  can  train,  fight,  and  win.  See  <www. 
navair.navy.mil>  for  more  information.^ 


For  more  information  about  CROSSTALK  co-sponsor- 
ship  or  for  more  information  on  how  to  become  a  co¬ 
sponsor,  please  contact  Tracy  Stauder  at  (801)  775-5746  or 
<tracy.stauder@hill.af.mil>. 
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The  2006  CROSSTALK  Editorial  Board 


Tracy  Stauder 
Crosstalk 


CROSSTALK  proudly  presents  its  2006  CROSSTALK  Editorial  Board.  Two  technical  reviewers,  in  addition  to  both  the 
publisher  and  associate  publisher,  review  each  article  submitted  to  CROSSTALK.  Most  reviewers  on  the  list  below  have  gra¬ 
ciously  offered  their  own  time  to  support  CROSSTALK’S  technical  review  process.  We  give  a  very  special  thanks  to  all  those 
participating  on  our  2006  CROSSTALK  Editorial  Board. 


COL  Ken  Alford,  Ph.D. 

Bruce  Allgood 
Brent  Baxter 
Jim  Belford 
Dan  Bennett 
Dr.  Alistair  Cockburn 
Richard  Conn 
Dr.  David  A.  Cook 
Greg  Daich 
Les  Dupaix 
Sally  Edwards 
Robert  W.  Ferguson 
Tony  Henderson 
Lt.  Col.  Brian  Hermann,  Ph.D. 

Thayne  Hill 
George  Jackelen 
Deb  Jacobs 
Dr.  Randall  Jensen 
Alan  C.  Jost 
Paul  Kimmerly 
Theron  Leishman 
Glen  L.  Luke 
Gabriel  Mata 
Paul  McMahon 
Mark  Nielson 
Mike  Olsem 
Glenn  Palmer 
Tim  Perkins 
Gary  A.  Petersen 
Vern  Phipps 
David  Putman 
Kevin  Richins 
Thom  Rodgers 
Larry  Smith 
Elizabeth  Starrett 
Tracy  Stauder 
Kasey  Thompson 
Dr.  Will  Tracz 
Jim  Van  Buren 
Dr.  Rayford  B.  Vaughn  Jr. 

David  R.  Webb 
Mark  Woolsey 


National  Defense  University 
84th  Space  &  C3I  Sustainment  Group 
Software  Technology  Support  Center 
Software  Technology  Support  Center 
Software  Technology  Support  Center 
Humans  and  Technology 
Retired  (formerly  with  Microsoft) 

The  AEgis  Technologies  Group,  Inc. 

Science  Applications  International  Corporation 

Software  Technology  Support  Center 

Information  Technology  Standards  and  Solutions  Branch 

Software  Engineering  Institute 

Software  Technology  Support  Center 

Air  Force  Institute  of  Technology 

Software  Technology  Support  Center 

GAITS,  Inc. 

Focal  Point  Associates 

Software  Technology  Support  Center 

Raytheon 

Defense  Finance  and  Accounting  Service 
Northrop  Grumman 
Software  Technology  Support  Center 
Software  Technology  Support  Center 
PEM  Systems 

Software  Technology  Support  Center 
Science  Applications  International  Corporation 
L-3  Communications,  Inc. 

Independent  Consultant 
Shim  Enterprise,  Inc. 

Oasis  Systems  Inc. 

309  SMXG  Software  Maintenance  Group 
Shim  Enterprise,  Inc. 

Software  Technology  Support  Center 

Software  Technology  Support  Center 

Software  Technology  Support  Center 

Software  Technology  Support  Center 

Software  Technology  Support  Center 

Lockheed  Martin  Integrated  Systems  and  Solutions 

Charles  Stark  Draper  Laboratory 

Mississippi  State  University 

309  SMXG  Software  Maintenance  Group 

Software  Technology  Support  Center 
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The  Project  Charter  -  Blueprint  for  Success 

Chuck  McKeever 
GCI,  Inc. 

Projects  are  tricky,  that  is  why  many  fail;  however,  a  good  project  charter  is  a  valid  solution  to  help  your  teatn  and  organisa¬ 
tion  deliver  projects  successfully. 


According  to  Plato,  “The  beginning  is 
the  most  important  part  of  the  work.” 
On  April  30,  1492,  King  Ferdinand  and 
Queen  Elizabeth  of  Castile,  Spain,  issued 
a  charter  and  provided  Christopher 
Columbus  with  the  necessary  vessels  and 
men  to  discover  and  subdue  islands  and  a 
continent.  The  expedition  charter  was  the 
realization  of  Columbus’  dream;  after 
many  years  of  work,  he  convinced  the 
monarchy  of  the  benefits  of  the  project, 
and  they  sponsored  his  endeavor  with 
resources.  Additionally,  based  on  the 
potential  danger,  they  agreed  to  reward 
him  after  the  successful  conquest  with  a 
promotion  to  admiral  and  governor.  This 
historic  project  charter  resulted  in  the  dis¬ 
covery  of  America  and  remarkable  riches 
for  the  project  sponsors,  project  manager, 
and  Spain. 

Unfortunately,  this  project  success 
story  is  the  exception,  not  the  norm. 
Based  on  many  research  studies  and  pub¬ 
lic  project  failures,  many  projects  fail  due 
to  a  variety  of  reasons  such  as  poor  defi¬ 
nition,  poor  planning,  lack  of  commit¬ 
ment,  etc.,  causing  organizations  to  lose 
billons  of  dollars,  customers,  and  time. 

In  1994,  the  Standish  Group,  a  project 
management  and  information  technology 
company,  published  its  landmark,  original 
“Chaos  Report”  [1]  finding  that  American 
companies  wasted  $81  billion  on  canceled 
information  technology  projects.  In  its 
2001  updated  research,  the  Standish 
Group  found  that  executive  support  is  the 
most  critical  factor  to  project  success. 
Companies  that  practiced  senior  manage¬ 
ment  support  of  projects  were  more  like¬ 
ly  to  achieve  positive  results  and  reduce 
problems  throughout  the  project  life 
cycle.  Additionally,  projects  that  did  not 
have  proper  sponsorship  —  but  were  still 
continued  —  delivered  such  poor  function¬ 
ality  that  most  users  would  not  count 
them  as  successful  projects. 

One  recent,  high-profile  failure  is  the 
Federal  Bureau  of  Investigation’s  (FBI) 
Virtual  Case  File  (VCF)  project  that  wast¬ 
ed  more  than  $170  million  of  taxpayer 
money;  it  is  beset  with  cost,  schedule,  and 
technical  problems,  and  is  still  not  fielded. 
VCF  is  the  case  management  system  com¬ 


ponent  of  the  FBI’s  information  technol¬ 
ogy  upgrade  program  known  as  Trilogy. 
In  February  2005,  the  Department  of 
Justice  Office  of  the  Inspector  General 
found  that  “FBI  management  did  not 
exercise  adequate  control  over  the  Trilogy 
project  and  its  evolution  in  the  early  years 
of  the  project”  [2].  Despite  good  inten¬ 
tions,  the  lack  of  proper  project  manage¬ 
ment  controls  and  processes  doomed  this 
effort.  Unfortunately,  the  FBI  and  numer¬ 
ous  other  companies  and  organizations 
make  similar  errors  in  problem  initiation, 
which  results  in  wasting  precious 
resources  and  not  achieving  organization¬ 
al  goals. 

“The  project  charter 
is  a  stakeholders’ 
agreement,  providing 
the  written 

authorization  to  proceed 
with  a  project. ” 

This  article  describes  a  proven  solu¬ 
tion  that  improves  project  success 
through  better  communication,  defined 
roles,  and  confirmed  stakeholder  buy-in 
before  a  project  starts.  The  solution  is  a 
project  charter.  A  charter  is  a  tool  that 
obtains  commitment  from  all  affected 
groups  and  individuals  associated  with  a 
project. 

The  American  Heritage  Dictionary 
describes  a  charter  as  “any  written  instru¬ 
ment  given  as  evidence  of  agreement, 
transfer,  or  contract”  [3].  The  word  char¬ 
ter  originated  from  the  Latin  word,  char- 
tula,  which  meant  paper.  I  define  a  project 
charter  as  a  written  agreement  developed 
and  coordinated  by  the  customer  organi¬ 
zation,  the  organization  providing  the 
service  or  product,  and  other  key  stake¬ 
holders.  A  charter  authorizes  a  project, 
and  ensures  that  necessary  resources  and 
management  commitments  are  provided 


to  achieve  success.  It  is  a  tool  to  obtain 
commitment  and  ensure  understanding  of 
roles  and  responsibilities  from  all  affected 
groups  for  a  project  before  it  starts.  A 
project  charter  is  a  formal  agreement  that 
ensures  project  stakeholders  share  a  com¬ 
mon  understanding  of  why  the  project  is 
being  done,  the  timeframe,  deliverables, 
boundaries,  and  responsibilities.  The  proj¬ 
ect  charter  addresses  the  following: 

•  Roles,  responsibilities,  activities. 

•  Project  management  framework. 

•  Management  commitments. 

•  Stakeholders  and  partners. 

•  Customer  success  criteria. 

The  project  charter  provides  a  consol¬ 
idated  and  summary-level  overview  of  the 
project.  It  allows  all  stakeholders  to  agree 
on  and  document  project  scope,  objec¬ 
tives,  timeframe  approach,  and  deliver¬ 
ables.  The  project  charter  is  one  of  the 
first  steps  in  the  project  planning  process 
following  completion  of  the  project  initi¬ 
ation  phase.  The  project  charter  should 
not  be  confused  with  die  investment  busi¬ 
ness  case  (IBC).  The  IBC  should  already 
be  completed,  and  the  investment  deci¬ 
sion  to  proceed  with  a  project  should  be 
taken  before  a  project  charter. 

A  project  charter  is  also  not  a  project 
plan.  A  project  plan  is  more  detailed  and 
comes  later  in  the  project  cycle.  The  proj¬ 
ect  plan  is  a  comprehensive  plan  that  pulls 
together  all  the  outputs  of  project  plan¬ 
ning  activities,  which  include  project 
scope,  project  activities,  activity  sequence, 
activity  durations,  resources  required  for 
activities,  project  schedule,  cost  estima¬ 
tion,  spending  plan,  and  a  quality  plan. 

The  project  charter  is  an  effective 
planning  tool  used  in  the  project  initiation 
phase  and  is  a  communication  tool  that 
can  be  continually  referenced.  It  is  both  a 
quick  reference  guide  and  an  executive 
summary  of  what  the  project  is  about, 
why  it  is  being  done,  who  is  involved, 
roles  and  responsibilities,  schedule,  and 
general  approach.  It  also  helps  new  proj¬ 
ect  team  members  get  familiarized  with 
the  project  more  quickly  —  all  in  one  con¬ 
venient  document. 

The  project  charter  does  not  normally 
change  through  the  project  life  cycle.  It  is 
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created  at  the  beginning  of  the  effort, 
approved  by  key  stakeholders,  and  signed 
before  work  starts  on  a  project.  Many 
smart  organizations  have  implemented  a 
no-charter,  no-project  policy  to  improve 
efficiency  and  ensure  management  com¬ 
mitment.  The  project  charter  captures  the 
rationale  and  agreement  for  the  project  at 
the  time  of  initiation,  providing  a  baseline 
with  a  specific  date,  signatures,  and  for¬ 
mal  organizational  sponsorship. 

The  project  charter  is  a  single  refer¬ 
ence  about  the  project  regarding  planning 
and  initiation.  Of  course,  the  project 
charter  could  be  updated  later  in  the  proj¬ 
ect  cycle  if  all  parties  agree  to  new 
updates.  However,  its  primary  purpose  is 
project  authorization  and  kickoff.  It  pro¬ 
vides  information  about  scope,  objectives, 
deliverables,  risks,  and  other  issues.  It  lays 
the  foundation  for  how  the  project  will  be 
structured  and  managed  in  terms  of 
change  control,  oversight  risk,  and  issue 
resolution. 

The  Project  Management  Institute 
(PMI)  has  created  a  reference  guide  called 
“A  Guide  to  the  Project  Management 
Body  of  Knowledge  (PMBOK  Guide)” 
[4]  that  provides  generally  accepted 
knowledge  and  practices  used  in  the  proj¬ 
ect  management  profession.  The 
PMBOK  describes  the  project  charter  as 
“a  document  that  formally  authorizes  a 
project.”  The  project  charter  addresses 
important  aspects  of  a  project,  and  can  be 
linked  to  all  nine  knowledge  areas  that  are 
listed  in  the  PMBOK.  PMI  recognizes  the 
importance  and  utility  of  the  project  char¬ 
ter  and  considers  it  a  best  practice. 

Benefits 

The  project  charter  provides  a  consolidat¬ 
ed  and  summary-level  overview  of  the 
project.  It  allows  all  stakeholders  to  agree 
on  and  document  project  scope,  objec¬ 
tives,  approach  timeframe,  and  deliver¬ 
ables.  Collaboration  and  consensus  by  all 
key  project  participants  is  the  goal.  It  also 
captures  the  agreed-upon  communica¬ 
tions  plan,  control  mechanisms,  funding, 
and  responsibilities  of  team  members.  It 
is  the  fundamental  communications  tool 
within  the  project  environment.  The  proj¬ 
ect  charter  is  a  stakeholders’  agreement, 
providing  the  written  authorization  to 
proceed  with  a  project.  It  provides  a  his¬ 
torical  record  that  can  ensure  unity  of 
effort  and  defuse  conflict. 

Leading  organizations  and  seasoned 
project  managers  know  the  power  of  a 
well-written  project  charter.  For  example, 
in  a  heated  discussion  during  a  project’s 
monthly  status  review,  I  was  once  chal¬ 
lenged  as  the  project  manager  by  an  exec¬ 


utive  on  the  availability  of  engineering 
staff  to  support  a  $4  million  campus  fiber 
optic  cable  installation  project.  Instead  of 
reacting  to  the  harangue,  I  responded  to 
the  inquiry  calmly  by  simply  showing  the 
project  charter  and  pointing  out  where  Iris 
director  of  engineering  had  agreed  to 
provide  the  necessary  trained  installers 
and  equipment  to  support  the  schedule. 
Reluctantly,  the  executive  agreed  that  his 
organization  was  responsible  for  this 
work  and  would  accomplish  the  task  on 
schedule.  My  boss,  the  chief  information 
officer,  was  also  at  the  meeting,  and  was  a 
project  stakeholder.  He  smiled  at  me 
knowing  that  we  had  done  our  homework 
by  getting  the  necessary  signatures  on  the 
project  charter.  This  diffused  a  potential 
political  turf  battle.  The  project  charter 
helped  our  team  complete  our  project  on 
time,  on  budget,  and  to  specification, 
greatly  enhancing  our  automation  net¬ 
work  and  bandwidth  service  to  more  than 
2,000  users. 

A  project  charter  provides  the  addi¬ 
tional  following  benefits: 

•  Defined  roles  and  responsibilities. 

•  Better  project  sponsorship. 

•  Senior  management  commitment. 

•  Improved  project  management  pro¬ 
cesses. 

•  Increased  probability  of  project  suc¬ 
cess. 

The  development  of  the  project  char¬ 
ter  is  a  collaborative  activity;  any  one 
party  should  not  do  it  in  isolation  since  it 
outlines  an  agreement  between  the  proj¬ 
ect  stakeholders  of  what  the  project  will 
deliver  and  how.  The  project  manager  has 
ultimate  responsibility  for  ensuring  die 
project  charter  is  developed,  coordinated, 
and  approved.  Project  charters  can  have 
different  formats,  levels  of  detail,  and  sec¬ 
tions.  The  time  it  takes  to  prepare  a  proj¬ 
ect  charter  depends  on  the  organization, 
specifics  included  in  the  document,  and 
internal  procedures.  It  requires  time  to 
create;  the  time  invested  up  front  will  save 
lots  of  time  and  reduce  confusion  later 
due  to  improved  coordination  and  com¬ 
munication.  Each  organization  and  proj¬ 
ect  manager  can  tailor  the  charter  to 
describe  and  fit  the  project  as  appropriate. 
Based  on  experience  and  research,  I  rec¬ 
ommend  the  following  14  areas  be 
addressed  in  a  project  charter: 

1.  Project  Name 

The  project  name  identifies  the  unique 
project. 

2.  Project  Purpose 

The  project  purpose  is  a  brief  executive 
summary  description  of  the  project 


describing  the  reason  for  the  project, 
background,  intent,  and  expectations.  The 
purpose  describes  the  business  or  organi¬ 
zational  need  for  the  project.  The  follow¬ 
ing  example  of  a  project  purpose 
describes  the  organizational  rationale  for 
starting  a  project: 

Internet  electronic  commerce,  e- 
commerce,  is  used  daily  by  con¬ 
sumers  and  businesses  worldwide 
to  safely  buy  and  sell  goods  and 
services.  The  proposed  cost  sav¬ 
ings  and  productivity  improve¬ 
ments  that  can  be  achieved  by  e- 
commerce  are  substantial.  For  this 
reason,  the  E-Commerce  Project  is 
being  initiated  to  evaluate  specifi¬ 
cally  how  our  organization  can 
take  advantage  of  these  benefits, 
and  to  identify  infrastructure  and 
procedures  that  may  be  required  to 
adopt  dais  technology.  This  six- 
month  project  will  result  in  a  bet¬ 
ter  understanding  by  our  organiza¬ 
tion  of  the  benefits  and  require¬ 
ments  for  operating  in  an  electron¬ 
ic  commerce  environment. 

3.  Project  Scope 

The  project  scope  identifies  the  bound¬ 
aries  for  the  project  and  the  product  or 
service  that  will  be  provided.  The  project 
scope  identifies  what  work  will  be  per¬ 
formed  and  clearly  identifies  what  is  in 
scope  and  what  is  not  in  scope. 

4.  Project  Objectives 

Project  objectives  identify  what  the  proj¬ 
ect  is  intended  to  achieve  in  business  and 
technical  terms,  including  the  benefits  and 
efficiencies  to  be  gained.  Areas  that  proj¬ 
ect  objectives  might  address  include  oper¬ 
ational  improvements,  enhanced  readi¬ 
ness,  productivity  improvements,  market 
opportunities,  etc.  All  objectives  should 
be  based  on  the  SMART  goal  setting 
technique:  SMART  is  a  mnemonic  that 
stands  for  the  following: 

•  Specific. 

•  Measurable. 

•  Agreed. 

•  Realistic. 

•  Time  constrained. 

5.  Roles  and  Responsibilities 

Roles  and  responsibilities  are  specific 
positions  within  the  project,  which  are 
assigned  unique  authorities  and  duties. 
Four  roles  and  responsibilities  that  must 
be  identified  are  the  project  sponsor,  proj¬ 
ect  manager,  customer,  and  project  team. 
There  may  be  other  roles  and  responsibil¬ 
ities  such  as  finance,  engineering,  con- 
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tracts,  etc.  that  may  need  to  be  considered 
and  included  based  on  your  organization¬ 
al  environment. 

Sponsor 

The  sponsor  is  an  organizational  leader 
who  commits  political  capital,  resources, 
and  time  in  support  of  the  project.  The 
sponsor  is  normally  from  senior  manage¬ 
ment  and  is  often  the  project  champion. 
The  project  sponsor  maintains  ultimate 
authority  over  and  responsibility  for  the 
project.  Ideally,  the  sponsor  should  be 
able  to  make  75  percent  of  the  decisions 
without  getting  additional  approvals  from 
executive  management.  The  sponsor  is 
the  arbitrator  who  resolves  conflicts 
between  stakeholders  and  organizational 
departments  to  support  the  project  team. 

Project  Manager 

The  project  manager  has  overall  responsi¬ 
bility  for  the  project’s  success  and  reports 
to  the  project  sponsor.  The  project  man¬ 
ager  manages  the  project  on  a  day-to-day 
basis,  coordinates  all  activities,  and 
approves  work  products.  It  is  important 
to  list  the  project  manager’s  authority  and 
boundaries.  The  project  manager  devel¬ 
ops  and  executes  the  project  charter  and 
project  plan. 

Customer 

The  customer  will  be  the  beneficiary  and 
receive  the  results  of  your  project;  a  cus¬ 
tomer  could  be  a  person  or  organization. 
The  customer  representative  is  the  voice 
of  the  customer  and  represents  users  and 
customers  to  ensure  that  their  equities  are 
addressed. 

Project  Team 

The  project  team  consists  of  core  func¬ 
tional  and  technical  team  members  work¬ 
ing  together  to  produce  project  deliver¬ 
ables  and  work  packages.  The  stakeholder 
team  consists  of  individuals  and  organiza¬ 
tions  that  will  be  affected  by  the  project 
and  have  a  vested  interest  in  the  project’s 
success.  The  stakeholder  team  ensures  all 
business  and  technical  requirements  are 
addressed,  reviews  project  status,  pro¬ 
vides  feedback  to  the  project  team,  and 
reviews  project  deliverables. 

6.  Project  Approach 

The  project  approach  identifies  the  gener¬ 
al  strategy  for  completing  the  project  and 
explains  methods  and  processes  that  will 
be  used.  It  describes  the  project  team 
structure  and  outlines  the  project  plan.  A 
high-level  project  schedule  with  milestone 
dates  and  control  gates  should  also  be 
included.  Identify  any  key  interdependen¬ 


cies,  personnel,  and  relationships  outside 
the  control  of  the  project  team  that  will 
affect  project  success  such  as  dependent 
architecture  projects.  Address  how  deci¬ 
sion  making  will  be  done.  Include  your 
communications  strategy,  including  how 
the  project  team  will  communicate  and 
get  the  word  out,  i.e.,  meetings,  e-mail, 
Web  site,  etc.  If  you  have  a  tentative  idea 
of  the  project  completion  date,  include  it 
in  this  section. 

7.  Project  Deliverables 

This  section  provides  a  list  of  all  deliver¬ 
ables  that  will  be  generated  both  during 
and  upon  completion  of  the  project, 
along  with  milestones  with  dates.  A  high- 
level  summary  of  all  major  deliverables 
should  also  be  provided.  Every  deliver¬ 
able  should  provide  a  description  of  its 
quality  objective  and  approval  require¬ 
ment.  All  deliverables  must  be  specific 
and  measurable,  and  there  should  be  an 
ability  to  measure  the  quality  of  the  deliv¬ 
erable.  For  example,  weekly  project  status 
reports  provided  to  the  project  sponsor, 
project  team,  and  stakeholder  team 
improve  communication  and  customer 
satisfaction  by  keeping  everyone 
informed  of  progress. 

8.  Constraints  and  Assumptions 

Constraints  and  assumptions  identify  lim¬ 
itations  considering  the  current  and 
future  environment  the  project  must  sup¬ 
port.  These  factors  will  influence  many 
project  decisions  and  strategies. 
Dependencies  outside  of  the  project 
manager’s  control  should  be  identified. 
For  example,  activities  to  be  performed 
by  a  client  or  subcontractor  required  to 
support  the  project  must  be  documented. 
Beware  of  scope  creep  and  new  require¬ 
ments.  As  the  FBI’s  VCF  project  demon¬ 
strated,  an  organization  should  not  solely 
rely  on  a  prime  contractor  for  due  dili¬ 
gence  and  assumptions.  Unfortunately, 
there  is  often  a  conflict  of  interest.  The 
potential  impact  of  each  constraint  and 
assumption,  both  positive  and  negative, 
should  be  identified. 

9.  References 

Identify  any  documents,  decisions,  or  ref¬ 
erences  that  were  used  in  developing  the 
project  charter.  Include  the  date,  author, 
and  other  information  to  describe  the 
citation. 

10.  Terminology 

Describe  any  unique  terms  or  acronyms 
that  will  be  used  within  the  project.  Terms 
that  may  be  new  or  confusing  to  project 
stakeholders  should  be  clearly  explained. 


Avoid  technical  jargon  and  buzzwords. 
When  in  doubt,  spell  it  out. 

/  I.  Risk  Management 

Identify  risks  associated  with  the  project 
and  the  actions  that  can  be  taken  during 
project  execution  to  minimize  impact. 
Mitigation  strategies  and  planned  re¬ 
sponse  approaches  should  also  be  identi¬ 
fied.  What  are  your  contingency  plans  to 
deal  with  the  unexpected? 

12.  Project  Facilities  and  Resources 

The  project’s  requirements  for  funding, 
facilities,  resources,  office  space,  comput¬ 
er  equipment,  office  equipment,  unique 
security  requirements,  and  support  tools 
should  be  identified.  As  they  say  in 
Hollywood,  “Show  me  the  money.”  You 
should  include  your  tentative  budget  here 
so  the  organization  can  plan,  prioritize, 
and  provide  your  project  with  sufficient 
funding  for  success.  Other  areas  such  as 
training,  quality  assurance,  and  documen¬ 
tation  should  also  be  considered. 
Responsibilities  for  coordination  and  res¬ 
olution  of  these  issues  should  be  clearly 
assigned.  Any  service-level  agreement  or 
support  arrangement  should  be  docu¬ 
mented. 

13.  Performance  Measures 

The  project  should  identify  its  success  cri¬ 
teria.  List  the  agreed-upon  methods  for 
assessing  whether  project  goals  were 
achieved.  Performance  measures  use 
measurable  criteria  that  should  be  satisfied 
before  the  project  is  considered  complete. 

I  4.  Approval 

This  section  identifies  the  names  and 
roles  of  all  key  stakeholders,  including  the 
project  sponsor,  project  manager,  the  cus¬ 
tomer  representative,  and  other  key  proj¬ 
ect  personnel.  All  key  stakeholders  should 
sign  and  date  the  project  charter  to  docu¬ 
ment  the  agreement,  ensure  buy-in,  and 
provide  written  authorization  for  the 
project  to  begin. 

Summary 

A  project  charter  is  your  insurance  policy 
to  get  management  commitment,  re¬ 
sources,  and  stakeholder  buy-in  to  ensure 
success.  Another  selling  point  for  a  proj¬ 
ect  charter  is  that  it  helps  executives  and 
organizations  in  delegating  authority  and 
responsibility  to  a  project  manager.  It 
encourages  project  managers  and  func¬ 
tional  managers  to  work  together  and 
help  resolve  conflicts  at  the  lowest  orga¬ 
nizational  level  since  specific  roles  are 
identified  early  in  the  project  life  cycle.  A 
project  charter  is  a  proven  technique  to 
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properly  initiate  your  project  in  preparing 
for  tomorrow’s  achievements.  A  project 
charter  is  an  effective  tool  that  can  assist 
organizations  and  project  managers  with 
delivering  projects  more  successfully.  An 
anonymous  proverb  sums  it  up:  “The 
faintest  ink  is  more  powerful  than  the 
strongest  memory.”^ 
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Safety  Check® 


Steven  M.  Smith1 
EMC  Corporation 

You  have  heard  repeatedly  that  an  agenda  is  a  vital  ingredient  to  a  successful  meeting.  But  little  is  ever  heard  about  safety 
in  meetings  —  the  environmental  variable  that  determines  whether  people  participate  or  merely  observe.  How  do  you  meas¬ 
ure  safely ?  What  actions  are  available  to  leaders  for  creating  a  safe  meeting  environment ? 


He  is  wearing  his  traditional  garb:  dark 
suit,  white  button-down  shirt,  red  tie, 
and  black  tasseled  shoes.  The  glare  off  his 
wire -rimmed  glasses  makes  it  difficult  to 
see  those  steely  blue  eyes.  Harry  Fox  has 
all  the  right  moves,  and  his  quick  climb  up 
die  management  ladder  proves  it.  He  is 
arrogant  and  ruthless.  People  who  oppose 
his  ideas  pay  a  price.  And  the  payment  is 
extracted  when  they  can  least  afford  it. 

We  are  both  participating  in  a  prob¬ 
lem-solving  meeting.  Well,  that  is  not  quite 
true:  I  am  observing  and  Harry  is  talking. 
He  just  stole  the  floor  from  Jim  King  a 
few  minutes  ago  by  talking  louder  than 
Jim.  I  hate  that  behavior.  Jim  looks  deject¬ 
ed.  Harry  continues  to  dictate  his  ideas 
about  how  the  team  should  solve  the 
problem.  I  realize  that  Harry  missed  three 
crucial  facts,  which  will  cause  his  solution 
to  fail. 

Should  I  share  the  facts?  Wait  a 
minute.  Harry  does  not  like  to  be  correct¬ 
ed.  He  wants  to  hear  only  the  facts  that 
support  his  position.  Harry  is  connected 
all  the  way  to  die  top  of  the  company.  I 
am  connected  to  the  people  on  my  team.  I 
hesitate.  Wow,  that  is  totally  uncharacteris¬ 
tic  of  me:  I  am  known  as  someone  who 
speaks  his  mind.  I  look  over  at  Harry.  He 
has  taken  his  glasses  off  and  is  moving 
diem  rhythmically  up  and  down  as  he 
talks.  Although  what  he  is  saying  does  not 
make  sense,  it  sounds  authoritative.  I  feel 
my  gut  twisting.  Is  it  anger?  No.  It’s  fear. 

Harry  concludes  his  speech.  There  is  a 
pause.  If  I  want  to  speak,  it’s  time  ...  I  say 
nothing. 

Safety 

The  omission  of  crucial  facts  and  opin¬ 
ions  happens  in  thousands  of  business 
meetings  every  day.  If  people  do  not  feel 


safe,  they  are  not  going  to  say  anything. 
And  you  will  have  no  idea  about  what  you 
missed. 

Too  often  the  participants  who  are  the 
most  vocal  assume  that  everyone  feels  as 
safe  as  they  do.  This  assumption  is  wrong 
more  often  than  not.  But  it  is  rarely  ever 
tested. 

You  can  help  increase  the  safety  of 
your  meetings.  Collect  data  about  conver¬ 
sational  safety.  Share  it.  Interpret  it.  And 
decide  how  to  respond  to  it.  These  actions 
will  open  die  opportunity  to  transform 
your  meetings.  For  instance,  you  will  cre- 

“An  unsafe  environment 
causes  participants  to 
share  fewer  ideas  and  to 
carefully  filter  the  ideas 
they  do  share  to  be  sure 
they  are  safe  ” 


ate  the  opportunity  to  discuss  and  take 
action  on  items  previously  not  discussable 
such  as  who  was  or  was  not  invited;  what 
is  and  is  not  on  the  agenda;  and  how  the 
discussions  will  or  will  not  be  processed.  I 
have  experienced  the  power  of  this  trans¬ 
formation  many  times.  You  can  too. 

Collect  the  Data 

Inform  everyone  that  you  will  use  a  secret 
ballot  to  poll  the  participants  about  their 
safety  to  speak  freely.  Poll  people  with  the 
following  question:  “How  safe  is  it  for  you 
to  fully  share  your  ideas  during  this  meet¬ 
ing?” 


Write  this  question  on  die  board  or  a 
flip  chart.  Clarify  that  die  ballots  are  not 
identified,  just  a  number  on  a  slip  of 
paper.  Expand  on  what  fully  share  means  by 
listing  some  controversial  ideas  that  were 
not  shared  at  other  meetings  that  would 
have  made  a  difference. 

An  unsafe  environment  causes  partici¬ 
pants  to  share  fewer  ideas  and  to  carefully 
filter  die  ideas  they  do  share  to  be  sure 
they  are  safe.  Poll  people  for  the  informa¬ 
tion  in  Table  1 . 

Pass  out  a  ballot  -  a  small  piece  of 
paper,  Post-it  Note,  or  note  card  -  to  each 
participant.  Ask  everyone  to  write  the 
number  corresponding  to  their  level  of 
safety  on  die  ballot  using  the  numbers 
zero  through  four  as  defined  in  Table  1. 
My  experience  is  that  some  people  will, 
regardless  of  the  instructions,  write  a  dec¬ 
imal  number.  Simplify  things  for  yourself 
by  informing  everyone  that  all  the  ballots 
will  be  rounded  so  that  the  results  fit  the 
range  of  the  gradient. 

Ask  them  to  cup  the  ballot  in  their 
hand  when  writing  the  number  so  that  no 
other  participant  can  see  their  rating. 
Stress  to  everyone  that  you  do  not  want 
anyone  to  share  their  rating  with  anyone 
else,  regardless  of  how  safe  they  personal¬ 
ly  feel.  Again,  emphasize  that  only  you  will 
see  their  ratings.  Have  the  participants 
fold  the  ballot  in  half  and  place  it  in  a  con¬ 
tainer,  such  as  a  hat. 

Share  the  Data 

Ask  a  participant  to  help  you  build  a  his¬ 
togram  of  the  poll.  I  suggest  that  you  use 
a  flipchart  so  there  is  a  hard  copy  of  the 
histogram  to  use  when  you  write  up  the 
minutes  of  the  meeting.  Pull  each  ballot 
out  of  the  container  one-by-one  and  read 
the  score  to  the  person  building  die  his¬ 
togram.  Stuff  die  recorded  ballot  into  one 
of  your  pockets  or  put  them  in  your  brief¬ 
case  so  no  one  else  can  or  will  ever  see 
them.  Note  that  you  are  not  only  revealing 
how  safe  people  feel  -  you  are  also  build¬ 
ing  safety  by  checking  numbers  in  a  way 
that  reinforces  safety. 

Table  2  shows  an  actual  histogram 

®  Copyright  2005  Steven  M.  Smith. 


Table  1 :  A  Safety  Gradient 


Level 

Description 

Comment 

4 

Secure 

Everything  is  discussable  without  filtering. 

3 

Safe 

Almost  everything  is  discussable  without  filtering. 

2 

Neutral 

Most  things  are  discussable  without  filtering. 

1 

Dangerous 

Many  of  my  best  ideas  are  not  discussable. 

0 

Treacherous 

Most  of  my  best  ideas  are  not  discussable. 
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Safety  Check 


Level 

Description 

Number  of  People 

4 

Secure 

********** 

3 

Safe 

★ 

2 

Neutral 

**** 

1 

Dangerous 

**** 

0 

Treacherous 

Table  2:  The  Histogram  From  an  Actual  Safety  Check 


built  during  a  requirements-gathering 
meeting  that  I  facilitated  at  a  large  manu¬ 
facturing  company. 

Interpret  and  Respond 

Ask  the  participants,  “What  is  your  inter¬ 
pretation  of  the  histogram?”  A  manager 
in  a  requirements-gathering  meeting  said 
they  needed  to  start  trusting  each  other. 
His  management  colleagues  vigorously 
echoed  his  belief.  And  his  colleagues  had 
a  lot  more  to  say  about  the  importance 
of  trusting  each  other.  1  let  this  discus¬ 
sion  continue  for  10  minutes  and  asked, 
“What  cluster  of  people  on  the  his¬ 
togram  do  you  think  is  offering  the  most 
advice?”  The  room  fell  silent.  The  peo¬ 
ple  who  felt  the  safest  realized  that  they 
were  doing  the  most  talking.  They  real¬ 
ized  that  the  people  who  felt  threatened 
were  not  talking. 

Telling  people  how  they  should  feel 
does  not  work.  And,  in  my  experience, 
people  know  that  as  a  fact,  but  forget  to 
put  that  knowledge  to  work.  It  helps  to 
give  diem  a  gende  reminder.  Ask  everyone, 
“How  do  the  participants  who  feel  com¬ 
pletely  safe  help  the  participants  who  feel 
threatened?”  The  answers  I  have  heard  in 
meeting  after  meeting  can  be  summarized 
in  two  words:  care  and  listen. 

During  a  manufacturing  meeting,  peo¬ 
ple  did  start  to  care  and  listen.  The  partic¬ 
ipants  slowed  down  and  asked  each  other 
questions.  Most  importantly,  diey  were 
okay  with  moments  when  no  one  spoke.  I 
believe  that  silence  is  a  gift.  It  shows  peo¬ 
ple  that  you  are  ready  and  want  to  listen. 
And,  in  the  case  of  a  meeting,  silence 
demonstrates  that  the  group  is  ready  and 
wants  to  listen. 

These  changes  made  a  big  difference 
in  the  requirements  meeting.  The  discus¬ 
sions  were  deeper.  The  enriched  conversa¬ 
tion  enabled  the  discovery  of  require¬ 
ments  that  would  have  been  invisible  to 
diem.  They  were  more  effective  together 
than  they  had  ever  been. 

Other  Methods 

Another  method  that  can  help  create  safe¬ 
ty,  especially  in  large  groups,  is  to  let  the 
participants  build  die  safety  guidelines  for 
their  meeting. 

Split  the  participants  into  small  groups. 
The  ideal  size  is  a  triad  -  three  partici¬ 
pants.  Ask  the  groups  to  (1)  introduce 
themselves  to  each  other,  and  (2)  create  a 
set  of  guidelines  for  conducting  a  safe 
meeting.  Give  them  a  few  test  cases  to 
ponder.  For  instance,  someone  starts 
blaming  someone  else,  someone  tells  an 
inappropriate  joke,  or  someone  dominates 
die  meeting,  and  so  on.  Let  everyone 


know  that  they  should  not  limit  diem- 
selves  to  the  test  cases.  You  want  them  to 
share  any  guideline  that  will  make  the 
meeting  safer. 

The  hope  is  that  the  discussion  will 
help  remind  people  of  what  they  already 
know  about  safety,  and  remind  them  to 
practice  what  they  know.  Just  as  impor¬ 
tantly,  the  hope  is  that  a  connection  with  a 
small,  manageable  number  of  people  will 
increase  safety. 

Have  each  small  group  introduce  their 
members  and  share  the  safety  guidelines 
diey  created  with  everyone.  You  will  be 

“Another  method  that 
can  help  create  safety, 
especially  in  large 
groups,  is  to  let  the 
participants  build  the 
safety  guidelines  for 
their  meeting 


amazed  at  die  wisdom  diat  people  have 
about  safety.  Gain  agreement  from  every¬ 
one  on  which  guidelines  to  accept. 
Remind  diem  that  the  guidelines  are  dieirs 
rather  than  yours.  If  someone  violates  a 
guideline,  you  will  call  them  on  it. 

Ask  die  group  to  monitor  your  facilita¬ 
tion  and  to  inform  you  if  you  allow  any 
deviation  from  the  agreed-upon  guide¬ 
lines.  When  someone  mentions  a  devia¬ 
tion,  treat  it  with  die  utmost  care  and 
respect.  It  is  the  ultimate  demonstration  of 
die  value  you  put  on  safety. 

Final  Thoughts 

Although  the  methods  I  discuss  are  espe¬ 
cially  valuable  for  setting  the  right  tone  for 
organizational  improvement  efforts  or 
multi-day  meetings  such  as  a  project  retro¬ 
spective,  they  are  also  valuable  for  reoc¬ 
curring  meetings.  The  key  is  to  expose, 
explore,  and  respond  to  feedback  about 
safety.  If  followed,  the  feedback  will  take 
die  group  in  die  appropriate  direction. 


Feelings  about  safety  will  change  so  it  is  a 
wise  investment  to  have  a  process  for  peri¬ 
odically  exposing  and  responding  to  issues 
about  safety. 

Regardless  of  die  method  used,  you 
can  never  be  absolutely  certain  that  all  the 
participants  feel  safe.  If  someone  would 
have  asked  me  how  safe  I  felt  during  the 
meeting  with  Harry  Fox,  I  would  have 
voted  neutral  or  safe  so  that  Harry  would 
not  find  out. 

The  best  diat  you  can  do  is  to  solicit 
and  respect  everyone’s  ideas.  The  leader 
who  models  appropriate  behavior  in  meet¬ 
ing  after  meeting  is  constantly  renewing 
and  enriching  safety  and  productivity. 

Be  a  leader.  Care.  Listen.  Model  the 
behavior  you  want.^ 

Note 

1 .  The  views  expressed  in  this  article  are 
Smith’s  and  do  not  necessarily  reflect 
the  views  of  EMC. 
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Building  Successful  Software  Development  Teams 
Using TSP  and  Effective  Communication  Networks 

Dr.  William  R.  Nichols 

Bechtel  Bettis,  Inc. 

Social  network  models  can  help  explain  how  and  why  sotne  organisational  structures  and practices  work.  Moreover,  network 
analysis  is  accessible  to  engineering  practitioners  and  is  particularly  effective  in  helping  us  understand  the  value  of  Team 
Software  Process ™  (TSP™).  Networks  not  only  offer  an  explanation  of  how  TSP  works  with  respect  to  communication,  but 
also  suggest  that  as  we  scale  beyond  a  team  of  teams,  new  organisational  structures  will  be  required.  The  role  manager  struc¬ 
ture  sets  TSP  apart.  Teams  that  use  role  managers  take  advantage  of  a  proven  communication  pattern  that  scales  as  teams 
grow.  Successful  work  is  facilitated  by  effective  communication,  which  can  be  improved  with  specific  network  structures.  These 
structures  can  take  shape  through  the  self-organisation  of  teams  around  TSP  role  managers.  Unlike  the  traditional  tree  hier- 
arcly  that  you  see  on  most  organisational  charts,  the  more  flexible,  self-organising  network  can  respond  quickly  to  the 
demands  of  a  fast-paced  workplace. 


Every  software  development  organiza¬ 
tion  strives  to  build  successful  project 
teams.  But  almost  anyone  who  has  been 
part  of  a  growing  organization  has  seen 
formerly  successful  teams  fail  as  coordina¬ 
tion,  communication,  and  decision  making 
were  impeded  by  increased  team  size. 

As  a  Team  Software  Process™  (TSPSM) 
coach  and  team  lead,  I  have  struggled  with 
the  problems  of  getting  the  right  people 
talking  through  the  requirements,  syn¬ 
chronizing  schedules,  and  working 
through  the  problems  such  as  design  and 
configuration  control.  The  time  demands 
upon  a  lead  in  the  middle  of  these  deci- 


A:  Star 


sions  become  overwhelming.  Fortunately, 
TSP  encourages  role  managers  to  guide 
self-directed  teams  toward  making  deci¬ 
sions  and  completing  work. 

Role  managers  act  as  the  conscience  of 
the  team  within  certain  domains:  planning, 
design,  quality,  customer  interface,  imple¬ 
mentation,  test,  support,  and  process. 
Role  managers  need  not  do  the  associated 
domain  tasks,  but  rather  serve  as  points  of 
contact  and  ensure  that  the  work  is  done 
and  done  well. 

Watts  Humphrey  [1]  describes  the  rea¬ 
sons  for  role  managers.  I  found  that 
although  these  reasons  seemed  sound, 


B:  Web 


many  of  the  team  members,  including 
myself,  could  not  internalize  this  explana¬ 
tion.  The  epiphany  for  me  came  after  I 
used  a  pen  and  notepad  to  sketch  out  the 
principle  patterns  of  communication 
within  my  team  and  among  the  several 
teams  on  our  project.  I  discovered  that 
there  is  another  and  more  compelling  rea¬ 
son  that  roles  are  important  in  making 
TSP  work. 

The  patterns  were  based  on  subjective 
rather  than  actual  measurement;  nonethe¬ 
less,  I  discovered  that  I  could  demonstrate 
important  characteristics  of  our  group 
interactions  by  graphically  representing 
the  paths  of  communication.  As  if  it  were 
a  physical  network,  I  sketched  an  idealized 
version  of  a  team  reliant  upon  its  lead  for 
passing  information  and  making  deci¬ 
sions,  shown  in  Figure  1A.  I  represented 
team  members  as  nodes  and  the  communi¬ 
cation  links  as  lines  joining  the  nodes.  The 
hub  and  spoke  topology  formed  a  star 
with  the  team  lead  in  the  central  role. 

I  next  sketched  Figure  1 B  to  show  sev¬ 
eral  role  managers,  for  example,  the  plan¬ 
ning,  design,  and  customer  interface  role 
managers  assuming  responsibility  for  these 
important  knowledge  domains.  The  role 
manager  links  distributed  communication, 
thus  opening  new  paths  and  reducing  the 
communication  traffic  load  through  die 
team  lead.  Finally,  I  added  some  less-active 
roles  to  Figure  IB,  (testing  becomes  more 
active  late  in  a  project,  design  less  active) 
and  the  result  was  a  complete  network  fol¬ 
lowing  a  web.  I  reasoned  that  this  was  the 
team  that  would  keep  running  even  if  one 
or  two  key  members  became  unavailable. 

Using  this  graphical  approach,  I  was 
able  to  qualitatively  show,  by  following  the 
Figure  1A  pattern,  how  team  leads  had 
become  overloaded.  With  this  graphic,  I 
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Figure  1A  and  IB:  Star  and  Web  Network  Technologies 

O  Team  Lead 

•  Team  Member  (Less  Active  Role) 

O  Role  Manager  (Active  Role) 

Communication  with  Team  Lead 

-  Less  Active  Communication  with  Role  Manager 

-  More  Active  Communication  with  Role  Manager 
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O  Team  Lead 
O  Role  Manager 
•  Team  Member 

—  Intra-Team  Communication  Link 

Leadership  Team  Inter-Team  Communication  Link 
- -  Role  Team  Inter-Team  Communication  Link 


Figure  2:  Three  Teams  (Clusters)  Connected  bj  Team  Tends  and  Role  Managers 


was  able  to  show  how  the  team  leads  had 
become  botdenecks,  and  how  reinvigorat¬ 
ing  the  role  managers’  activity  would 
change  the  communication  patterns  to 
our  benefit. 

Role  Managers  Add 
Communication  Links 

A  necessary  condition  for  a  self-directed 
team  is  that  the  team  manages  all  tasks. 
TSP  teams  designate  role  managers  to 
assume  cognizance  of  important  task- 
based  information  domains  within  tire 
team.  But  the  benefits  of  role  managers 
extend  beyond  the  individual  team. 

Multiteam  TSP  (TSPm)  scales  the 
practice  of  TSP  to  larger  projects  contain¬ 
ing  more  than  one  team.  Across  the  proj¬ 
ect,  teams  of  role  managers  —  one  from 
each  team  -  form  affiliation  groups,  directing 
information  for  a  given  domain  through  a 
team  knowledge  node  —  the  role  manager 
—  to  the  greater  project,  thus  distributing 
project  information  traffic.  Figure  2  shows 
three  teams  (clusters)  communicating 
through  multiple  channels.  Communi¬ 
cation  traffic  is  heavier  within  teams  and 
lighter  between  teams.  The  primary  paths 
of  communication  between  teams  are 
through  team  leads  and  role  managers. 

Because  communication  becomes 
more  efficiently  directed,  there  is  less 
communication  traffic ,  and  nodes  no 
longer  get  as  many  busy  signals  when  seek¬ 
ing  information.  There  is  no  strategically 
placed  node  that,  when  lost,  would  cause  a 
catastrophic  failure.  Moreover,  the  infor¬ 
mation  most  commonly  needed  is  under 
the  cognizance  of  someone  who  knows  or 
can  gain  access  to  that  information  when 
it  is  needed. 

For  example,  a  new  team  member  may 
need  clarification  on  requirements.  The 
customer  interface  manager  may  or  may 
not  know  the  answer,  but  should  know 
whom  to  ask.  The  power  of  networks  is 
leveraged  through  this  selective  specializa¬ 
tion,  thus  information  becomes  readily 
available  through  the  network.  The  team 
leaders  are  still  important,  but  they  no 
longer  stand  out  or  create  bottlenecks  in 
the  network  topology.  By  creating  role 
teams,  we  have  enabled  the  team  of  teams  to 
function  as  a  small  world.  Everyone  in 
another  team  is  either  a  friend  or  a  friend  of 
a  friend.  Information  flows  within  and 
among  the  teams  with  very  few  intermedi¬ 
ate  connections. 

This  has  fundamentally  changed  the 
group  structure  and  dynamic.  The  smaller 
groups,  teams,  and  role  teams  can  invest  in 
social  capital  (spend  time  cultivating  rela¬ 
tionships)  required  to  form  tightly  knit 


teams.  Where  it  is  necessary  to  pass  infor¬ 
mation  between  groups,  we  know  who  the 
go-to  guy  is.  A  structure  has  emerged  that 
does  not  show  up  on  the  organizational 
chart. 

Team  and  Project  Size  Limits 

Physical  networks  have  physical  and  engi¬ 
neering  constraints.  Routers,  for  example, 
can  process  only  a  limited  bandwidth; 
transformers  in  an  electrical  grid  can  carry 
only  so  much  current.  Similarly,  human 
networks  have  constraints  that  must  be 
considered.  It  is  not  possible  to  work 
closely  with  a  large  number  of  people 
simultaneously.  As  working  groups 
become  large,  communication  requires 
more  overhead. 

In  “The  Mythical  Man  Month,”  [2] 
Brooks  points  out  that  there  are  n(n-l)/2 
potential  links,  leading  to  an  n-squared 
scaling  with  team  size.  A  team  of  15  has 
50  percent  more  links  than  a  team  of  12, 
more  than  twice  the  links  of  a  team  of  10, 
and  five  times  as  many  links  as  a  team  of 
seven.  Time  is  limited,  and  each  relation¬ 
ship  requires  time  for  maintenance. 
Because  of  this,  it  is  practical  to  keep 
working  groups  small  [3].  Some  claim  the 
sweet  spot  is  around  a  team  as  small  as  seven 


[4],  For  our  purposes,  we  will  place  the 
practical  upper  limit  at  12,  based  on  an 
observed  sociological  phenomenon 
known  as  an  empathy  group  [5],  Larger 
teams  can  exist,  but  they  will  usually  factor 
into  sub-teams. 

It  may  not  be  just  the  total  number  of 
potential  links.  Figure  1 A  suggests  that  the 
number  of  direct  links  any  individual  can 
support  may  limit  team  size.  In  Figure  1A, 
the  team  lead  is  the  central  node.  The 
communications  to  other  team  members 
are  represented  by  links  (communication 
channels)  to  other  nodes  (team  members). 
In  Figure  1A,  a  star  network  appears  to  be 
simple  and  elegant,  and  team  members 
communicate  primarily  through  the  lead 
who  is  a  hub  linking  the  nodes.  Most  ques¬ 
tions  are  resolved  by  asking  the  lead  for 
clarification  or  guidance.  There  is  no  inter¬ 
action  between  most  nodes.  However,  the 
hub  creates  a  communication  bottleneck. 
For  example,  if  the  person  acting  as  the 
hub  is  out  sick,  no  communication  can 
take  place,  no  guidance  can  be  provided, 
and  work  cannot  move  forward.  If  the 
hub  needs  to  manage  too  much  communi¬ 
cation,  some  will  not  take  place.  If  you 
limit  your  team  communication  to  flow 
through  one  centralized  point,  it  rapidly 
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becomes  less  effective,  and  because  of  the 
bottleneck  effect,  team  size  can  no  longer 
scale. 

To  achieve  maximum  scaling  within  a 
team,  encourage  efficient,  point-to-point 
communication.  Distribute  the  communi¬ 
cation  traffic  in  a  decentralized  network. 
By  distributing  the  communication  traffic 
through  many  node-to-node  pairs,  the 
traffic  becomes  balanced  and  bottlenecks 
are  eliminated.  If  one  node  is  removed, 
others  can  easily  replace  it.  The  cost  is  the 
time  needed  to  build  and  maintain  the 
relationships.  But  the  resulting  Web  net¬ 
work  is  strong  and  flexible;  it  provides 
ongoing,  efficient  communication  that 
keeps  information  flowing  and  tasks  mov¬ 
ing  forward. 

Consider  Figure  IB  as  an  alternative. 
In  this  communication  model,  the  team 
lead  has  delegated  responsibility.  TSP  does 
this  naturally  through  the  role  managers 
who  assume  responsibility  not  only  for 
domain  knowledge,  but  also  for  tracking 
tasks  within  that  domain.  Adding  several 
highly  active  roles  significantly  increases 
tire  available  routes  for  moving  informa¬ 
tion  between  any  two  points.  The  commu¬ 
nication  traffic  is  distributed  so  that  the 
team  lead  no  longer  stands  out  in  tire  net¬ 
work  topology. 

Inclusion  of  the  less  active  roles  per¬ 
mits  most  sorts  of  information  essential  to 
project  success  to  be  communicated 
directly.  In  the  language  of  networks,  we 
have  converted  a  network  with  average 
node-to-node  degree  of  separation  (die 
number  of  links  drat  a  message  must  tra¬ 
verse  between  two  nodes)  of  nearly  two,  to 
one  with  an  average  degree  of  separation 
of  one.  This  small  degree  of  separation, 
along  with  plenty  of  direct  communica¬ 
tion,  is  another  key  to  project  success. 

Degrees  of  Separation  and 
Small  Worlds 

The  degree  of  separation  is  important  for 
tire  team  and  project  because  it  affects  the 
flow  and  accuracy  of  information  that 
teams  need  to  be  successful.  Noah 
Friedkin  of  the  University  of  California  at 
Santa  Barbara  has  shown  that  die  limit  of 
observability  in  organizations  is  only  about 
three  degrees  of  separation  [6].  This  is 
intuitively  consistent  with  how  we  may  use 
die  friend  of  a  friend  (two  degrees  of  separa¬ 
tion)  to  gather  information  or  to  access 
other  parts  of  the  organization.  However, 
at  three  degrees,  the  view  becomes  cloudy; 
at  four,  it  becomes  opaque.  This  makes 
sense  if  you  consider  some  common  bar¬ 
riers  to  clear  communication: 

1.  Messages  are  imperfect.  The  sender 


and  receiver  can  understand  an  ambigu¬ 
ous  or  vague  message  differently. 

2.  When  information  is  directed 
through  a  node,  that  node  acts  as  a 
filter.  The  message  is  filtered  through 
that  person’s  experience,  knowledge, 
and  priorities.  Each  node  can  change  a 
message  in  subtle  ways  that,  when 
added  together,  result  in  an  original 
sender  and  final  recipient  understand¬ 
ing  very  different  meanings. 

3.  The  technical  means  of  communi¬ 
cation  are  imperfect  or  incomplete. 
Most  communication  channels  include 
signal  loss  or  noise.  The  telephone 
loses  facial  cues.  E-mail  loses  facial 
and  vocal  inflection.  Video  conferenc¬ 
ing  has  inconsistent  sound  and  visual 
signal  delays.  Any  of  these  can  cause 
unintended  interpretations  of  commu¬ 
nication. 


“Teams  of  role 
managers  not  only  make 
the  network  a  small 
world ,  but  also  serve  to 
make  the  network 
searchable,  greatly 
shortening  the  average 
communication  path.” 

The  upshot  is  that  a  functioning  team 
must  be  kept  to  an  average  of  three  or 
fewer  degrees  of  separation,  much  like  the 
small  world  network  described  by  Duncan 
Watts  and  Steven  Strogatz  [7],  The 
essence  of  a  small  world  is  that  everyone 
knows  everyone  else  through  a  very  short 
chain  of  handshakes.  This  recalls  the  well- 
known  concept  of  six  degrees  of  separation 
that  was  based  on  a  famous  experiment  by 
Stanley  Milgram  [8],  Watts  and  Strogatz 
described  transforming  a  network  into  a 
small-world  network  by  adding  only  a 
small  number  of  random  links.  Local  clus¬ 
ters,  in  our  case  teams,  are  the  smallest  of 
small  worlds.  Their  world  becomes  even 
smaller  by  adding  a  few  role  managers. 
Role  managers  direct  information  through 
standard  and  commonly  understood  chan¬ 
nels.  Teams  of  role  managers  not  only 
make  the  network  a  small  world,  but  also 
serve  to  make  die  network  searchable, 
greatly  shortening  the  average  communi¬ 
cation  path.  This  becomes  particularly 
important  as  projects  and  teams  grow. 


Scaling  Up  to  Teams  of  Teams 

When  the  project  size  scales  up,  teams 
must  deal  with  the  stresses  that  come  with 
the  increased  numbers.  The  British 
anthropologist  Dunbar  [9,  10,  11]  noted 
that  group  size  tends  to  saturate  at  around 
12,  similar  to  the  empathy  group  described 
by  Buys  and  Larsen  [5].  This  saturation 
occurs  when  the  necessary  investment  in 
social  capital  becomes  too  large;  at  that 
point,  the  groups  then  fission  into  smaller 
groups.  Dunbar  also  noted  that  the  larger 
social  network  is  limited  to  about  150, 
which  is  due  to  tire  human  capacity  to  rec¬ 
ognize  and  track  personal  facts  about  all 
members  of  a  group. 

Below  1 50  group  members,  a  relatively 
informal  structure  is  sufficient  because 
peer  pressure  and  personal  loyalty  are  ade¬ 
quate  to  maintain  discipline  and  control. 
Larger  groups  need  a  formal  command 
structure  to  maintain  order.  For  example, 
the  Hutterites,  a  rural  North  American 
group  drat  practices  communal  living,  limit 
each  community  to  150  members  [12]. 
Throughout  history,  basic  military  battle 
groups,  comparable  to  a  modern  army 
company,  remained  near  this  limit.  Many 
working  groups  and  businesses  fail  at  dais 
point  as  efficient  communication,  knowl¬ 
edge,  and  informal  control  structures  break 
down.  Interestingly,  Dunbar  noted  that 
where  groups  exceeded  the  nominal  upper 
bounds,  it  was  typical  that  roles  had  evolved, 
(e.g,  sheriff,  minister)  that  permitted  peo¬ 
ple  to  interact  appropriately  with  the  role. 

The  size  thresholds  of  12  and  150  can 
be  used  as  rules  of  thumb  -  heuristic  guide¬ 
lines  -  where  we  expect  a  new  social  order 
to  accompany  increased  group  size.  When 
combined,  the  thresholds  at  12  and  150 
have  implications  for  successful  develop¬ 
ment  teams.  Virtual  teams  of  role  man¬ 
agers  or  team  leads,  drawn  from  each  of 
the  product  teams,  are  the  glue  that  binds 
a  project  into  a  small  world.  What  happens 
as  these  virtual  teams  grow  in  size? 

It  is  interesting  to  note  drat  role  teams 
reach  a  size  of  12  (12  teams)  at  about  the 
same  time  that  the  project  reaches  a  size 
of  150,  a  number  that,  after  all,  is  very 
close  to  12  teams  of  12.  In  this  way,  the 
rules  of  12  and  150  converge.  TSPm,  on  a 
modest-sized  project,  fits  within  limits 
imposed  by  these  rules  of  12  and  150. 
However,  scaling  TSPm  beyond  this  size, 
perhaps  to  many  hundreds  or  thousands, 
becomes  problematic  when  the  role  teams 
that  deal  with  inter-team  coordination 
become  too  large.  The  next  level  of  scal¬ 
ing  appears  to  require  either  additional 
communication  structures  or  substantial 
independence  of  subprojects. 
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The  Organizational  Chart 
Versus  Self-Organization 

Organizational  structure  can  be  a  power¬ 
ful  factor  in  a  project’s  success.  In  any 
organization,  there  are  charts  that  show 
die  official  organizational  hierarchy,  but 
they  probably  do  not  represent  the  inter¬ 
action  patterns  and  functional  organiza¬ 
tion  through  which  work  gets  done  —  the 
result  of  self-organization  that  occurs  in 
successful  software  development  teams. 
Traditional  organizational  hierarchies  are 
effective  for  imposing  structure  and  con¬ 
trol,  but  they  are  not  effective  for  manag¬ 
ing  creative  work  in  frequendy  changing 
environments  such  as  those  common  to 
software  development.  Therefore,  to  man¬ 
age  effectively,  we  must  work  with  the 
actual,  self-organized  network  through 
which  work  gets  done. 

Fostering  self-organization  and  flexi¬ 
ble  communication  within  a  commonly 
understood  structure  solves  this  problem. 
The  TSP  role  managers  and  role  teams 
satisfy  this  need,  providing  a  way  to  organ¬ 
ize  a  project’s  information  patterns  for 
maximum  efficiency  and  effectiveness. 
This  form  frees  team  leaders  from  con¬ 
stantly  managing  communication,  allow¬ 
ing  diem  to  focus  on  strategic  issues. 

Formal  leadership  retains  its  impor¬ 
tance  for  managing  resources  and  setting 
business  goals,  but  assumes  a  different 
role  widi  respect  to  information,  commu¬ 
nication,  and  getting  work  done.  A 
changed  environment  requires  the  net¬ 
work  to  change  as  well.  Formal  hierarchies 
are  slow  to  change,  which  is  insufficient  in 
a  dynamic  environment.  Self-organizing 
networks,  however,  are  flexible.  They 
adapt  to  a  dynamic  environment  and  can 
lead  to  success  where  less  adaptable,  for¬ 
mal  hierarchies  fail.  Instead  of  trying  to 
constantly  restructure  our  formal  hierar¬ 
chies,  we  should  look  for  ways  to  leverage 
die  phenomenon  of  the  self-organizing 
network.  Self-organization  within  the  role- 
team  framework  becomes  die  key  to  flex¬ 
ibility  and  meeting  goals  in  an  ambiguous 
and  changing  environment. 

Conclusion 

The  key  actions  for  building  successful 
team  communications  are  to  identify  orga¬ 
nizational  needs,  encourage  the  right  roles, 
support  self-organization,  and  coach  indi¬ 
viduals.  In  addition  to  encouraging  the 
self-organization  of  role  teams,  consider 
die  organizational  priorities  and  support 
necessary  to  encourage  and  sustain  the 
right  roles.  From  a  TSP  standpoint,  we 
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should  coach  teams  and  projects  to  tailor 
roles  so  diere  is  a  central  focus  for  the 
project  or  organizational  priorities. 

Also  consider  additional  ways  to 
reduce  the  organizational  path  lengdis. 
For  example,  encourage  customer  inter¬ 
face  managers  to  form  user  groups,  which 
reduce  your  path  length  to  die  user,  prob¬ 
ably  to  as  few  as  two  or  diree  degrees.  TSP 
coaching  is  another  resource  that  must  be 
kept  to  a  short  padi  length.  Most  effective 
is  one  degree  of  separation.  For  a  success¬ 
ful  effort,  people  need  ongoing,  one-on- 
one  coaching. 

As  shown  earlier,  relying  on  a  tradi¬ 
tional  organizational  hierarchy  makes  a 
project  vulnerable  to  single  node  failure 
and  information  bottlenecks,  and  does  lit¬ 
he  to  reduce  path  lengths.  But  we  can  use 
what  we  have  learned  about  networks  to 
address  these  problems  in  a  flexible  team 
environment. 

Keep  small  teams  tightly  coupled  with 
many  internal  links,  as  shown  by  the  web 
network  in  Figure  1 B.  Fewer  links  between 
teams  are  adequate  to  maintain  short, 
inter-team  path  lengdis  throughout  the 
organization  as  shown  in  Figure  2.  This 
model  fits  within  human  limits  and  scales 
up  to  a  team  of  teams.  Strong  ties  support 
the  detailed  and  creative  work  within 
teams.  Some  team-to-team  links  are  neces¬ 
sary  to  convert  a  project  or  organization 
into  a  small  world.  Weaker  ties  bind  the 
teams  to  a  project  and  make  the  network 
searchable.  Role  teams  build  communica¬ 
tion  paths  starting  from  the  context  of 
important  task  domains.  Role  teams  are  a 
natural  mediod  for  TSP  to  add  these 
cross-team  links. 

The  network  model  shows  us  how  valu¬ 
able  functioning  role  managers  can  be  to 
die  success  of  small-world,  self-organized 
networks.  They  can  balance  information 
flow,  provide  alternate  paths  if  congestion 
develops,  and  make  information  easier  to 
find.  Fostering  self-organization  within 
teams  and  critical  role-manager  communi¬ 
cation  among  teams  can  be  highly  motivat¬ 
ing.  Properly  motivated  and  prepared  teams 
are  capable  of  extraordinary  tilings.  ♦ 
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E-Mail  Etiquette 


COL  Kenneth  L.  Alford,  Ph.D. 

National  Defense  University 


E-mail  is  out  of  control,  and  you  can  help  fix  it  by  following  the  suggested  rules  of  e-mail  etiquette  outlined  in  this  article. 


When  I  was  first  introduced  to  e-mail 
in  the  mid-80s,  it  was  a  wondrous 
invention.  And  I  loved  it!  I  could  now 
reach  out  and  asynchronously  communi¬ 
cate  with  others  regardless  of  time  or 
space.  The  few  e-mails  that  arrived  each 
day  were  handled  quickly  and  actually 
improved  productivity. 

From  a  trickle  in  the  1 980s,  e-mail  grew 
to  a  flood  in  the  1990s.  Today  the  flood  has 
become  a  tidal  wave.  It  is  not  uncommon  for 
workers  to  receive  more  than  a  hundred  (and 
in  too  many  cases,  hundreds)  of  e-mails 
every  day.  Important  e-mails  are  too  often 
buried  in  a  sea  of  minutia,  and  e-mail  can 
now  actually  reduce  productivity. 

Here  are  some  simple  rules  to  keep  in 
mind  so  that  you  can  be  part  of  the  solution 
and  not  add  to  this  growing  problem: 

•  Put  the  Bottom  Line  Up  Front.  In  the 
first  sentence  of  your  e-mail,  explain  why 
you  are  sending  the  e-mail:  what  you 
need,  what  your  position  is,  what  the 
problem  is,  what  your  solution  is,  etc. 

•  Keep  It  Short.  Get  to  the  point.  Avoid 
stream-of-consciousness  e-mails  that  ramble 
aimlessly. 

•  One  Message,  One  Topic.  limit  each 
e-mail  message  to  a  single  topic,  request, 
comment,  or  position. 

•  Talk  Face-to-Face.  Too  many  e-mails 
are  sent  to  people  who  work  in  the  carrel 
or  office  next  door.  It  is  often  easier  and 
faster  to  talk  with  a  co-worker  than  to 
send  an  e-mail  message,  but  too  many  of 
us  type  and  click  instead  of  getting  up 
and  walking  a  few  feet. 

•  Keep  Subject  Lines  Accurate.  If  a 
message  from  a  subordinate  triggers  a 
new  thought,  make  sure  that  you  change 
the  subject  line  before  you  click  Send  on 
your  return  message. 

•  Use  Subject  Tags.  One  or  two  topic 
words  at  the  beginning  of  an  e-mail  can 
make  it  easier  for  recipients.  For  example, 
tags  like  budget  or  Project  Kolob  can  help 
readers  quickly  evaluate  incoming  mes¬ 
sages. 

•  EOM  Tag.  Establish  an  office  code 
such  as  EOM  [end  of  message]  or  END 
that  can  be  placed  at  the  end  of  an  e- 
mail  subject  line  to  indicate  that  the 
entire  message  is  contained  in  the  sub¬ 
ject  line.  For  example,  Dept  Mtg,  Tnes. 
1100,  Ban  101,  EOM.  This  saves  readers 


from  having  to  open  those  messages. 

•  Read  Twice,  Send  Once.  Proofread 
your  e-mails  before  you  send  them. 
Typos  in  dates,  times,  locations,  and  facts 
can  result  in  tremendous  wasted  effort. 
Stop  the  problem  at  its  source. 

•  Self-Censor.  Never  write  and  send  an  e- 
mail  when  you  are  angry  or  frustrated. 
You  will  regret  it  later. 

•  Sending  Messages.  While  it  may  be 
easier  to  send  your  message  using  an 
organization-wide  distribution  list,  the 
chances  are  good  that  everyone  does  not 
need  to  receive  it  Send  messages  only  to 
people  who  need  to  read  them. 

•  Forwarding  Messages.  Whenever  pos¬ 
sible,  do  not  forward  messages! 

•  Replying  to  Messages.  Just  because  an 
announcement  was  broadcast  to  every¬ 
one  in  your  organization,  it  does  not 
mean  that  you  need  to  reply  to  everyone. 
Pick  your  To  and  Cc  recipients  with 
thought. 

•  Less  Is  More.  Reply  to  or  generate  e- 
mail  only  when  necessary.  If  you  had  a 
nickel  for  each  “Yea,  I  think  so,  too”  or 
“That’s  a  good  idea”  e-mail  you  have 
received,  you  could  probably  retire  in 
comfort. 

•  Use  E-mail  Tools.  Ensure  you  have  a 
spam  filter.  Use  rules  and  message  filters 
to  remove  clutter  from  your  inbox. 

•  Check  Attachments.  Take  a  moment  to 
open  each  e-mail  attachment  before  you 
send  it  -  to  ensure  that  you  are  attaching 
the  latest  version  of  the  correct  file. 

•  Follow  E-mail  Etiquette  Rules.  There 
are  numerous  Web  sites  that  list  rules  of 
e-mail  etiquette.  Please  take  a  few  min¬ 
utes  to  visit  those  Web  sites,  and  encour¬ 
age  employees  in  your  organization  to  do 
the  same. 

On  days  when  e-mail  is  particularly 
oppressive  (which  lately  has  been  most  days), 
I  sometimes  fantasize  about  inventing  a  new 
product:  The  E-mail  Terminator.  It  would  work 
something  like  this:  Every  night  at  midnight, 
individual  employee  e-mail  counters  would 
be  reset  to  zero.  Throughout  the  day,  the 
counter  would  keep  track  of  the  number  of 
e-mails  sent.  When  the  counter  reaches  a  pre¬ 
set  number,  the  e-mail  server  would  automat¬ 
ically  turn  off  that  employee’s  ability  to  send 
e-mail.  That  user  would  have  to  wait  until  the 
following  day  to  send  e-mail  again.  (That 


actually  was  not  my  first  idea,  but  I  think  that 
the  Exploding  Kyboard  idea  might  have  diffi¬ 
culty  receiving  Occupational  Safety  and 
Health  Administration  approval.) 

May  your  efforts  to  tame  your  e-mail 
be  successful!^ 

Additional  Reading 

1.  E-mail  Netiquette.  Yale  University 

Library  <www.library.yale.edu/ 

training/ netiquette>. 

2.  E-mail  Etiquette.  West  Virginia  Uni¬ 
versity  <http:/ / oit.wvu.edu/ support/ 
tss/email/Email%20Etdquette.pdf>. 

3.  Online  Writing  Lab.  Purdue  University 
<http://owl.english.purdue.edu/hand 
outs/ pw/ p_emailett.html>. 

4.  E-mail  Etiquette.  Tufts  University 
<http://ase.tufts.edu/its/email 
Etiquette.htm>. 
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A  Manager’s  Guide  to  Supporting 
Organizational  Change:  10  Lessons  Learned® 

Esther  Derby 

Esther  Derby  Associates,  Inc. 


Change  has  become  a  constant  in  organisations  —  whether  through  choice  or  changes  in  the  external  environment.  Change  is 
seldom  easy,  but  tnanagers  can  make  a  difference  by  communicating  reasons,  respecting  values,  attending  to  emotions,  and pro¬ 
viding  as  much  information  as  possible. 


By  now,  most  of  us  have  heard  the 
phrase,  “The  only  constant  is  change.” 
Markets  change,  technology  changes,  new 
economies  emerge.  The  expectations  of 
the  workforce  shift,  demand  wanes  or 
grows.  Our  ability  to  respond  successfully 
to  change  -  as  individuals  and  organiza¬ 
tions  —  marks  the  ability  to  stay  vibrant 
and  competitive  or  fall  by  the  wayside. 

Whether  the  change  involves  an  entire 
enterprise,  reorganization,  or  the  adoption 
of  new  software  development  methods, 
there  is  one  constant  in  any  change: 
People  need  and  crave  information,  time, 
and  support.  When  those  factors  are 
absent,  transitions  flounder,  and  hoped- 
for  changes  fail. 

Managers  at  all  levels  can  contribute  to 
successful  transitions.  In  this  article,  I  will 
draw  on  my  experience  observing,  leading, 
and  participating  in  organizational  change 
to  distill  practical  ways  that  managers  can 
support  intentional  change. 

But  first,  here  is  a  little  tale. 

A  Cautionary  Tale 

Not  long  ago  I  visited  a  large,  well-estab¬ 
lished,  multi-national  company.  After 
spending  a  day  talking  with  developers  and 
project  managers  about  software  develop¬ 
ment  methods,  I  had  a  chance  to  talk  to 
the  chief  information  officer  (CIO). 

The  CIO  spoke  about  Iris  vision  for 
transforming  the  organization.  He 
bounced  with  enthusiasm  as  he  strode 
back  and  forth  across  the  room  and  spoke 
about  reorganizing  his  800-person  soft¬ 
ware  development  department  within  the 
next  three  weeks  and  shipping  a  vast  new 
product  —  Galileo  —  in  six  months. 

“I’m  bringing  in  training  so  11  teams 
can  hit  the  ground  running  next  month,” 
he  enthused.  “I’ve  announced  the  reor¬ 
ganization  and  appointed  a  steering  com¬ 
mittee.  Of  course,  we  still  have  to  finish 
the  Green  River  project  and  deliver  that 
on  time.”  He  frowned  for  a  moment,  and 
then  resumed  his  energetic  bouncing. 
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“We’ve  been  working  on  this  product  for 
three  years,  but  with  this  new  organiza¬ 
tion,  we’ll  finish  Green  River  and  ship 
Galileo  by  the  end  of  the  year!” 

As  the  CIO  began  to  wind  down,  I 
asked  if  he  was  interested  in  hearing  what 
I  had  learned  from  the  people  actually 
building  software.  “They  love  it,  right?”  he 
asked,  pumping  his  fist. 

But  when  I  reported  that  most  of  the 
people  I  had  spoken  to  did  not  understand 
the  reason  for  the  change,  the  CIO 
became  annoyed.  “Over  two-thirds  of  the 
people  I  talked  to  feel  like  senior  manage¬ 
ment  is  ramming  this  change  down  their 
throats,”  I  said.  “They  don’t  see  the 
urgency,  and  they  do  not  see  how  it’s 
going  to  help.” 

“What  do  they  mean  ramming!?”  the 
CIO  demanded.  “They’ve  had  plenty  of 
time  to  get  onboard.  And  they  say  they 
don’t  know  about  dais!”  he  was  nearly 
shouting.  “I  talked  about  it  at  our  annual 
meeting  last  quarter!” 

I  am  sure  dais  executive  had  a  clear 
vision  and  goal  for  transforming  his 
organization.  I  am  sure  he  considered  the 
need  and  urgency  to  change.  I  know  he 
considered  many  options  before  deciding 
on  how  to  reorganize  the  department  and 
adopt  a  new  way  of  working. 

Like  most  CIOs,  dais  man  is  bright  and 
cares  about  the  success  of  his  organiza¬ 
tion.  And  he  fell  into  a  common  mistake: 
He  assumed  that  since  he  had  thought 
through  the  implications  of  the  change, 
announced  the  change  in  an  important 
setting,  and  established  an  aggressive  goal, 
he  had  done  his  job.  Sure,  he  has  gotten  a 
steering  committee  (made  up  of  people 
who  do  not  actually  write  the  software, 
and  who  had  so  far  produced  a 
PowerPoint  presentation).  And,  he  funded 
some  training. 

Given  the  financial  reserves  of  the 
company,  they  may  survive  for  a  while. 
But  this  CIO’s  hopes  for  transformation 
are  doomed.  What  could  he  have  done, 
and  what  can  other  managers  do  to  suc¬ 
ceed  at  transitions  in  organizations? 


Communicate  a  Compelling 
Reason  to  Change 

Most  people  want  to  know  the  why  behind 
a  change,  the  reason  they  should  do  things 
differently.  Announcements  are  not 
enough.  For  example,  “Starting  in  April, 
we  will  be  using  a  new  method!”  does  not 
convey  a  compelling  reason  to  change. 
Without  an  understanding  of  the  reason 
for  a  change,  any  proposed  change  seems 
arbitrary  —  the  latest  management  whim. 

Though  the  end  goal  may  be  wonder¬ 
ful,  the  process  of  change  brings  disrup¬ 
tion,  discomfort,  and  loss.  Most  people 
will  endure  the  downside  of  change  to 
achieve  a  compelling  goal  or  save  some¬ 
thing  they  value  —  but  not  to  provide  a 
prerequisite  to  someone  who  seems  dis¬ 
connected  and  capricious. 

One  manager  announced  an  aggres¬ 
sive  change  agenda  with  the  following 
rationale:  “I  need  you  to  be  up  and  run¬ 
ning  the  new  development  platform  by 
June.  My  birthday  is  in  June  and  this  will 
be  my  birthday  present.”  It  is  hard  to 
imagine  an  announcement  that  would 
have  done  more  damage  to  motivation 
and  goodwill. 

In  contrast,  another  executive  stood  in 
front  of  his  department  and  laid  out  the 
facts:  “We’ve  been  very  successful  in  the 
past.  Perhaps  we’ve  been  too  successful, 
and  we’ve  lost  our  edge.  We  are  losing 
market  share.  Our  competitors  are  build¬ 
ing  better  products  and  building  them 
faster.  The  way  we  have  done  our  work 
has  served  us  well  in  the  past,  but  it  is  no 
longer  serving  us.  I  know  we  can  regain 
our  place  in  the  market.  And  to  do  that, 
we  have  to  change.”  He  went  on  to 
describe  his  vision  for  how  the  depart¬ 
ment  needed  to  reinvent  the  way  they 
worked. 

People  did  not  leave  the  department 
meeting  “pumped  up;”  they  did  leave  with 
a  sense  of  purpose  and  a  clear  under¬ 
standing  that  their  leader  was  asking  for 
shared  sacrifice  to  save  the  company  they 
all  cared  about. 
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Communicate  Formally  and 
Informally 

Formal  communications  —  meetings  and 
memos  -  are  necessary,  but  they  are  not 
sufficient  in  times  of  change  and  transi¬ 
tion.  People  need  to  know  how  the  new 
direction  relates  to  their  day-to-day  work. 
Managers  at  all  levels  need  to  talk  about 
how  the  change  relates  to  day-to-day  deci¬ 
sions,  actions,  and  events  fl] . 

Look  for  opportunities  to  discuss  dif¬ 
ferences  and  similarities  with  new  meth¬ 
ods  or  structures  during  team  meetings 
and  one-on-one  meetings.  Look  for  water- 
cooler  moments  and  other  informal 
opportunities  to  tie  the  new  regime  to  cur¬ 
rent  concerns. 

One  group  I  worked  with  was  moving 
from  a  waterfall  life  cycle  to  iterative, 
incremental  development.  Soon  after  the 
first  announcement,  a  group  manager  set 
up  a  special  forum  to  answer  questions 
and  hear  concerns  about  die  transition  to 
iterative,  incremental  development. 
During  the  forum,  the  group  manager  led 
die  discussion  to  help  people  start  think¬ 
ing  about  how  their  work  would  change, 
and  what  they  would  need  to  do  different¬ 
ly  to  deliver  software  incrementally. 

Most  people  need  to  hear  a  new  idea 
many  times  before  they  absorb  and  inte¬ 
grate  the  new  information.  This  is  espe¬ 
cially  true  when  the  new  way  of  doing 
tilings  is  significantly  different  from  cur¬ 
rent  practices.  As  people  hear  about  a 
change  and  talk  through  how  it  supports 
company  goals,  they  mentally  rehearse 
how  they  will  accomplish  work  using  dif¬ 
ferent  means  or  different  methods.  For  a 
significant  change,  this  will  not  happen  in 
a  day  or  a  week.  Significant  transformation 
requires  time. 

Personalize  the  Message: 

What  Does  This  Mean  for  Me? 

People  want  answers  to  questions  about 
how  a  change  will  affect  them,  and  how  his 
or  her  job  will  change. 

In  one  workshop  on  agile  methods,  it 
dawned  on  a  vice  president  that  transi¬ 
tioning  to  agile  development  did  not  just 
involve  developers  and  testers.  He  had  to 
change  die  way  he  did  his  job,  too.  As  this 
sunk  in,  his  demeanor  changed,  and  his 
participation  in  the  workshop  trailed  off. 

During  a  break,  I  talked  to  him.  “Am  I 
even  going  to  have  a  job  once  our  teams 
are  using  agile  methods?”  he  asked. 

Until  people  know  what  part  they  will 
play,  and  how  die  change  will  impact  diem 
directly,  people  withdraw  into  worry.  Their 
energy  is  not  available  to  work  on  change 
or  on  the  business  of  the  organization. 


Someone  on  die  executive  level  can 
only  answer  questions  like  this  in  general¬ 
ities;  people  will  look  to  their  supervisors 
to  gain  information.  The  more  prepara¬ 
tion  and  information  direct  supervisors 
have,  the  better  equipped  diey  will  be  to 
answer  questions. 

And,  it  is  impossible  to  have  all  the 
answers.  Draw  die  picture  of  what  you  do 
know  and  the  boundaries  of  what  is 
unknown. 

Acknowledge  the  Unknowns 

The  maxim,  “I’ll  communicate  something 
when  I  know  something,”  does  not  work 
in  change  situations.  In  times  of  change, 
people  fill  in  the  blanks  widi  their  worst 
fears.  Every  bit  of  factual  information 
helps. 

The  statement,  “I  don’t  know,”  is  more 
helpful  dian  no  communication  at  all. 
When  you  do  not  know  an  answer,  tell 
people  when  you  will  report  on  progress 
finding  answers. 

Most  people  do  not  expect  their  man¬ 
agers  to  be  perfect  and  all-knowing.  They 
will  accept  when  you  are  not  able  to  find 
answers.  Be  sure,  though,  not  to  let  ques¬ 
tions  fall  into  a  black  hole.  Reporting  that 
you  have  no  new  information  is  better 
dian  silence. 

Surface  Rumors  and 
Fill  in  the  Blanks 

At  Q-Factor,  a  software  company,  I 
observed  a  large  staff  meeting  where  a 
project  team  was  discussing  an  upcoming 
management  transition.  One  fellow  leaned 
over  to  die  person  next  to  him  and  joked 
diat  die  new  management  team  was  going 
to  lock  the  team  down  for  weekend  over¬ 
time.  By  the  next  day,  the  rumor  had 
spread  to  the  entire  team.  People  latched 
onto  the  original  joking  statement  as  fact. 
Team  members  were  incensed.  Already 
distracted  by  news  of  die  change,  dieir 
productivity  plummeted.  The  team  spent 
die  day  grumbling  and  planning  their 
(angry)  response  to  the  anticipated 
demand  for  overtime. 

Rumors  thrive  on  lack  of  credible 
information.  One  simple  thing  managers 
can  do  is  regularly  ask,  “What’s  the  scut- 
debutt?  What  are  die  latest  rumors  and 
gossip?”  Bringing  rumors  out  into  the 
open  deprives  them  of  their  power  and 
provides  a  chance  to  replace  rumors  with 
solid  facts,  or  at  least  informed  denials. 

While  it  is  important  to  quash  rumors, 
diey  can  also  be  a  source  of  information. 
Rumors  also  provide  a  clue  about  what 
people  are  worried  about,  and  where  they 
are  having  trouble  finding  information. 


Look  for  patterns  and  fill  in  with  factual 
information  and  frank  discussion  of 
unknowns. 

Practice  What  You  Preach 

When  management  actions  do  not  match 
the  changes  they  are  asking  others  to 
make,  people  grow  cynical.  One  director 
extolled  the  virtues  of  self-organizing 
teams  to  the  technical  staff,  but  continued 
to  dictate  the  details  of  team  membership 
and  assignments.  He  even  stopped  by 
developers’  desks  to  give  them  advice  on 
how  to  write  code.  He  talked  the  talk  but 
his  actions  showed  he  did  not  walk  the 
walk  of  self-organization. 

Another  executive  introduced  a  major 
cost-cutting  initiative  to  his  organization. 
He  directed  middle  managers  to  cut  train¬ 
ing  budgets  and  cancel  orders  for  replace¬ 
ment  equipment.  Most  managers  under¬ 
stood  the  reasons  for  reducing  costs,  but 
felt  resentful  when  diey  saw  the  executive 
redecorating  his  office.  “Why  should  we 
scrimp  while  he’s  looking  at  carpet  sam¬ 
ples  and  fabric  swatches  for  his  new  digs?” 
one  asked.  “He’s  making  it  harder  for  me 
to  get  work  done  and  to  retain  staff.” 

Successful  change  requires  changes 
from  everyone,  not  just  the  lower  levels  of 
the  organization.  Wise  managers  do  not 
ask  other  people  to  make  changes  diey  are 
not  willing  to  make  themselves. 

Sometimes  it  only  looks  like  there  is  a 
contradiction  between  what  die  executives 
say  and  what  die  executives  do.  For  exam¬ 
ple,  the  corporate  jet  may  look  like  an 
unnecessary  expense,  but  careful  financial 
analysis  reveals  that  die  jet  actually  saves 
money.  Explain  die  apparent  inconsisten¬ 
cies  to  avoid  die  appearance  of  hypocrisy 
and  the  resultant  cynicism. 

On  a  smaller  scale,  one  manager  in  a 
change  effort  attended  a  local  conference 
during  a  period  of  budget  cutting.  He  was 
careful  to  explain  to  his  peers  and  staff 
that  the  period  for  a  full  refund  had  passed 
by  die  time  the  cost  reduction  edict  came 
down,  and  he  felt  it  was  wiser  to  attend. 

Acknowledge  and  Build  on 
What  People  Value 

In  periods  of  change,  people  struggle  hard¬ 
est  to  keep  what  diey  value  most.  People  do 
not  change  based  on  logic;  they  change  to 
keep  something  diat  is  valuable  to  diem. 

Unfortunately,  it  is  not  always  easy  for 
people  to  articulate  what  diey  value  about 
the  way  they  do  their  work.  I  find  that  ask¬ 
ing  the  question  a  different  way  helps  sur¬ 
face  the  information.  As  people  work  out 
the  details  of  how  the  new  ways  will  work, 
ask,  “What  were  the  strengths  of  the  way 
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we  have  been  doing  things?  How  do  those 
strengths  map  to  the  new  way?” 

Acknowledge  that  the  old  way  was  not 
stupid  or  bad  -  it  worked  well  at  one  time, 
but  it  does  not  fit  the  current  context. 

Reframe  Resistance 

When  people  resist,  the  natural  tendency 
is  to  push  harder,  give  more  reasons,  or 
even  threaten.  But  exploring  tire  response  to 
change  can  be  a  source  of  important 
information. 

According  to  Dale  Emery  [2],  people’s 
response  to  change  involves  four  main 
factors: 

•  Expectations. 

•  How  the  change  has  been  communi¬ 
cated. 

•  Relationships  with  the  person  request¬ 
ing  change. 

•  Other  factors  in  the  environment. 

When  faced  with  a  change,  some  peo¬ 
ple  are  afraid  they  will  not  be  able  -  or  will 
not  have  time  —  to  learn  the  new  skills, 
methods,  or  procedures  to  be  successful 
with  the  change.  People  who  do  not 
believe  they  can  be  successful  are  reluctant 
to  try  a  new  way. 

Sometimes  people  are  not  interested  in 
learning  new  skills;  that  is  worth  discover¬ 
ing,  too. 

How  a  person  feels  about  his  or  her 
direct  manager  and  management  colors  what 
they  hear.  Even  if  people  have  never  spo¬ 
ken  to  the  senior  executive,  they  have  a 
relationship  with  him  based  on  their  good 
or  ill  regard  for  him.  Communication  from 
a  well-respected  executive  will  garner  more 
attention  titan  communication  from  one 
they  regard  as  inept  or  irrelevant.  And  peo¬ 
ple  are  less  likely  to  want  to  go  through  the 
disruption  of  a  change  for  someone  with 
whom  they  have  a  negative  relationship. 

Past  experience  with  change  will  affect 
how  people  greet  die  current  change  ini¬ 
tiative.  When  past  change  efforts  have 
failed,  fizzled,  or  flopped,  people  will  be 
understandably  skeptical.  When  you  hear 
someone  say,  “It  won’t  work  here,”  or 
“We’ve  tried  that  before,”  it  is  a  clue  that 
people  have  been  burned  in  the  past. 
Arguing  will  not  help,  but  curiosity  may. 
Probe  to  find  out  what  is  behind  the  cate¬ 
gorical  statements.  You  may  uncover  use¬ 
ful  information  that  will  help  you  avoid 
pitfalls  with  the  current  change.  Or  you 
may  be  able  to  point  out  what  has  changed 
since  the  last  time  that  makes  the  change 
more  likely  to  succeed  this  time. 

Resistance  is  a  label  that  cuts  off  a  con¬ 
duit  for  information.  Resistance  is  when 
someone  is  not  doing  what  you  want  them 
to  or  expect  diem  to.  Listen  and  probe  to 
find  out  why. 


People  Do  Not  Resist  Change, 
They  Resist  Coercion 

I  used  to  agree  with  people  who  said, 
“People  hate  change.”  In  reality,  people 
choose  change  all  the  time  —  big  changes. 
People  choose  to  marry,  to  have  children 
or  adopt  children,  to  divorce,  to  move  in 
with  mom,  or  to  join  the  military.  These 
are  all  life-altering  changes.  Yet  people 
choose  diem  freely.  Most  of  the  time,  peo¬ 
ple  buck  up  and  muddle  through  when 
change  is  thrust  upon  diem  by  circum¬ 
stances.  Most  people  manage  to  find  dieir 
way  through  to  the  other  side  of  that 
change  event.  Clearly,  people  do  not  hate 
all  change,  nor  do  they  resist  all  change.  I 
have  come  to  realize  that  they  do  not  resist 
change  itself;  they  resist  coercion. 

People  will  reject  even  insignificant 
changes  when  they  feel  coerced.  One  team 
was  willing  to  try  agile  methods.  They 
were  willing  to  move  into  a  shared  work¬ 
space  and  try  pair  programming.  But 
when  the  facilities  manager  informed 
diem  they  had  to  give  up  die  coffee  pot 
one  of  the  team  members  had  brought 
from  home,  they  balked  —  even  diough  the 
facilities  manager  was  willing  to  allow  an 
industrial  coffee  maker  provided  by  the 
company  cafeteria. 

The  reality  is,  it  is  impossible  to  make 
someone  else  change.  Lay  out  the  reasons, 
acknowledge  the  emotions,  provide  sup¬ 
port,  and  give  people  a  chance  to  choose 
change. 

Not  everyone  will  change  at  the  same 
pace,  and  some  people  may  choose  not  to 
change  at  all.  If  diere  is  another  place  in 
die  organization  where  diey  can  be  valu¬ 
able,  support  them  to  find  diat  place,  and 
if  there  is  not,  support  them  to  move  on. 

Empathize 

Every  so  often,  I  run  into  a  manager  who  is 
not  very  patient  widi  people  going  dirough 
change.  Stan  was  one  such  manager.  “Move 
on  or  move  out,”  he  declared  at  a  staff 
meeting.  “We’re  not  paying  you  to  moan 
about  the  way  things  used  to  be.”  Another 
manager  listened  to  his  team  grieve  about 
die  changes  they  were  experiencing  and 
stated,  “I’ve  thought  about  it,  and  there’s  no 
reason  for  you  to  feel  that  way.” 

In  reality,  change  involves  loss:  loss  of 
routines,  relationships,  turf,  expertise,  and 
status  [3].  It  is  normal  for  people  to  expe¬ 
rience  intense  emotions  during  times  of 
change.  Pretending  those  emotions  do  not 
exist  will  not  make  them  go  away;  failing 
to  acknowledge  emotional  responses  may 
actually  prolong  and  amplify  diem. 

This  does  not  mean  managers  need  to 
play  psychologist;  diey  do  need  to  listen, 


empathize,  and  acknowledge  that  feelings 
are  real  and  valid. 

Real  change  takes  time.  The  CIO  I 
talked  about  at  die  beginning  of  this  article 
expected  to  complete  a  major  transforma¬ 
tion  in  a  matter  of  weeks.  Transitions  diat 
involve  significant  changes  —  new  methods 
or  reorganizations  -  are  measured  in  months 
and  years,  not  days  and  weeks. 

Expect  that  the  world  around  you  will 
shift  during  the  transition  and  be  prepared 
to  adapt  to  new  opportunities  and  circum¬ 
stances.  Be  willing  to  refine  goals  and  plans 
based  on  new  information  from  both 
inside  and  outside  die  organization.  Plan 
for  small  wins  and  celebrate  those  wins. 

Start  change  communication  with  a 
compelling  reason  for  die  change,  then 
communicate,  communicate,  communi¬ 
cate  until  the  people  begin  to  forget  they 
ever  did  things  a  different  way.^ 
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Transforming  Cultures:  A  New  Approach  to 
Assessing  and  Improving  Technical  Programs 


Hile  Rutledge  Jennifer  Tucker 

OKA  Boo ^  Allen  Hamilton 

Our  previous  article  in  February  2004  CROSSTALK,  ‘The  Human  Dynamics  of  IT  Teams,  ’’focused  on  the  personal¬ 
ity  dynamics  of  sy stems  development  teams,  and  factors  contributing  to  the  effectiveness  and  success  of  these  teams.  This  fol¬ 
low-up  article  takes  the  next  step,  providing  a  unique  methodology  for  assessingprogram  dynamics,  and for formulating  action 
plans  for  targeted  change.  Our  goal  is  to  describe  the  different  elements  contributing  to  culture  —  a  key  area  of  attention 
required  to  meet  Department  of  Defense  transformation  efforts  in  the  years  ahead. 


A  major  theme  is  emerging  from  today’s 
Department  of  Defense  (DoD)  trans¬ 
formation  efforts:  cultural  change.  As  the 
DoD  moves  towards  netcentricity,  bring- 
ing  power  to  the  edge ,  there  is  shared  recog¬ 
nition  that  successful  transformation 
requires  fundamental  changes  in  DoD  cul¬ 
ture.  How  will  we  accomplish  this  change? 
It  has  been  a  common  question  at  confer¬ 
ences  and  forums  across  the  DoD,  and  the 
answer  has  been  consistent:  “Changing 
culture  —  that  is  the  hard  part.” 

Transforming  cultures  is  difficult 
because  culture  emerges  from  the  myriad 


Mission:  Unifying  statement  defining 
the  organization’s  work  and  driving 
purpose. 

Leadership:  Responsible  for  bringing 
the  mission  to  fruition,  setting  both 
tone  and  direction. 

Structure:  How  formal  power  is 
distributed  and  labor  is  divided. 
Processes:  How  work  is  organized  to 
accomplish  the  mission. 

People:  How  relationships  are 
managed,  and  how  human  capital  is 
leveraged  for  greatest  effectiveness. 
Money:  Funding  issues  often  signal 
deeper  concerns,  and  lead  to  conflict 
between  the  mission  and  constraints. 
Environment:  The  collective  set  of 
needs,  expectations,  and  constraints 
set  by  the  external  environment. 
Culture:  The  set  of  commonly  held 
rules,  expectations,  and  consequences 
that  ultimately  identify  who  we  are. 


choices  that  individuals,  teams,  and  organ¬ 
izations  face  every  day.  Culture  changes 
slowly,  incrementally  —  and  often  painfully 

—  one  person  and  action  at  a  time. 
Deliberate  culture  change  comes  only 
when  the  individuals  who  make  up  sys¬ 
tems  and  teams  look  at  their  daily  work 
from  different  perspectives,  open  up  to 
the  possibility  of  new  choices,  and  see  the 
intricate  interrelationship  of  elements  and 
forces  that  make  up  human  systems. 

Over  the  past  few  years,  we  have 
refined  a  practical  model  for  breaking 
down  and  assessing  these  diverse  elements 
comprising  culture.  Called  the  Wrapped 
Cable  Model',  it  is  a  comprehensive  and 
scaleable  tool  for  diagnosing  and  inter¬ 
preting  the  challenges  that  exist  within 
technical  organizations,  programs,  and 
teams.  The  Wrapped  Cable  Model  pulls 
together  eight  interdependent  parts,  each 
playing  a  critical  role  (see  Figure  1).  If  a 
fray  exists  in  any  part  of  the  model,  the 
entire  cable  -  and  the  entire  organization 

—  suffers. 

Assessing  Programs  Using  the 
Wrapped  Cable  Model 

Let  us  start  by  outlining  the  eight  elements 
of  the  Wrapped  Cable  Model,  with  exam¬ 
ples  from  DoD  programs.  As  with  any 
useful  model,  it  is  flexible,  designed  to 
focus  on  the  most  critical  elements  of  a 
group’s  culture,  and  the  relationship  each 
has  to  others.  The  model  is  not  designed  - 
nor  is  this  article  presented  -  to  be  the 
definitive  statement  on  leadership,  organi¬ 
zational  structure,  mission,  culture,  or 
change.  It  is,  however,  a  useful  tool  for 
stepping  out  of  and  reflecting  on  the  sys¬ 
tems  within  which  we  work. 

Mission 

A  central  element  of  every  organization 
and  program,  the  mission  is  strategically 
placed  at  the  center  of  the  Wrapped  Cable 
Model.  While  the  DoD  may  share  the 
overall  mission  of  defending  our  country, 
each  organization  and  team  within  that 


structure  ultimately  carries  its  own  mis¬ 
sion  as  well  -  a  specific  statement  sup¬ 
porting  the  larger  whole.  The  mission  is  a 
unifying  statement  that  defines  and  focus¬ 
es  the  group’s  work  and  driving  purpose. 
In  an  ideal  setting,  the  mission  presents  a 
clear  and  unifying  purpose,  and  is  under¬ 
stood,  respected,  and  acted  upon  by  all 
team  members. 

Often,  however,  the  mission  is  not 
adequately  articulated,  or  related  to  the 
goals  people  are  actually  working  toward. 
When  a  mission  fails  to  provide  focus  or 
unification,  or  is  too  vague  or  rigid,  the 
organization  can  fall  out  of  balance  and 
problems  can  arise.  For  example,  large 
programs  often  involve  diverse  stakehold¬ 
er  organizations  with  differing  perspec¬ 
tives  of  what  the  mission  really  is.  One 
may  concentrate  on  delivering  a  system 
that  offers  the  lowest  life-cycle  cost; 
another  may  concentrate  on  allowing  the 
future  substitution  of  innovative  technol¬ 
ogy.  Mission  clarity  and  the  right  incen¬ 
tives  are  critical  to  program  success  —  and 
only  come  when  the  program  team  overt¬ 
ly  acknowledges  and  focuses  attention  to 
these  differences.  Mission  clarity  can  also 
help  address  the  dual  problems  of  scope 
and  requirements  creep;  using  the  mission 
as  a  central  tool  in  trade-off  analysis 
allows  a  team  to  carefully  evaluate  its 
options,  even  amidst  the  complexity  of 
technical  decision  making. 

Leadership 

Leadership  is  ultimately  responsible  for 
bringing  the  mission  to  fruition  and  is, 
therefore,  critical  to  organizational  and 
team  effectiveness.  We  define  leadership 
as  the  intentional  use  of  power  with  indi¬ 
viduals  or  groups  toward  some  desired 
end.  As  such,  anyone  who  exercises  his  or 
her  power  to  effect  change  is  a  leader.  At 
any  level,  leaders  set  the  tone  and  direc¬ 
tion  of  the  program  or  organization.  For 
meaningful  change  to  take  place  in  any  sit¬ 
uation,  leadership  must  be  exercised  at  all 
levels;  even  those  without  organizational 
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Wrapped  Cable  Model  Questions 

Here  is  a  starting  point: 

•  What  is  the  mission  of  your  organization  or  program?  How  does  it  link  to  the  over¬ 
all  DoD  mission?  How  does  the  work  you  do  right  now  support  that  mission? 

•  How  are  incentives  aligned  with  the  mission? 

•  How  does  your  mission  differ  and/or  is  the  same  as  other  parts  of  the  program? 

•  What  does  success  look  like?  How  do  you  know  you  are  successful? 

•  To  whom  do  you  look  for  leadership?  Who  has  the  power  to  get  things  done? 

•  Who  do  you  have  on  the  speed  dial  of  your  phone?  Why? 

•  Where  is  your  organization  chart?  How  does  it  relate  to  the  real  connections 
between  people? 

•  How  do  you  use  your  work  breakdown  structure?  Where  is  the  critical  path? 

•  When  do  you  encounter  conflict?  How  is  it  handled  when  you  do? 

•  What  could  make  you  more  efficient? 

•  How  do  you  know  where  your  role/organization/scope  starts  and  ends? 

•  How  is  morale?  If  asked  six  months  ago,  would  the  answer  be  different? 

•  Who  is  your  key  customer?  Who  is  the  true  end  user? 

•  How  are  customer/user  relationships  created,  maintained,  and  ended? 

•  How  do  users  differ  from  beneficiaries?  How  is  the  difference  reflected  in  your 
stakeholder  management  processes? 

•  What  metaphor,  image,  or  picture  would  you  use  to  describe  your  program/ 
organization? 

•  What  stories  do  people  tell  to  new  employees?  To  each  other? 


authority  need  to  exercise  die  power  they 
have,  be  it  relational,  intellectual,  tactical, 
etc.,  for  missions  to  be  fulfilled  and  for 
change  to  take  root. 

For  the  DoD,  the  regular  reassignment 
of  military  leaders  represents  a  unique 
formal  leadership  challenge.  While  civilian 
leaders  provide  needed  stability  during 
these  transitions,  uncertainty  and  readjust¬ 
ment  inevitably  accompany  these  changes. 
Will  the  new  leader  be  more  externally 
focused  with  stakeholders,  or  more  inter¬ 
nally  focused  on  team  process?  When 
tradeoffs  between  scope,  time,  and  cost 
are  required,  what  will  happen?  All  leaders 
bring  their  own  unique  experiences  and 
interpersonal  style.  Effective  leaders 
understand  their  impact  and  act  to  sup¬ 
port  both  the  mission  and  the  needs  of 
die  people  involved.  In  addition  to  the 
formal  leadership  of  any  system,  however, 
we  must  also  pay  attention  to  the  power 
exercised  by  all  players  regardless  of  their 
level,  title,  or  tenure  within  the  project  or 
organization. 

Structure 

The  structure  of  an  organization  illus¬ 
trates  how  formal  power  is  distributed  and 
labor  is  divided.  Structure  is  closely  linked 
with  leadership  because  examining  it  often 
reflects  the  alignment  or  gaps  between 
authority,  responsibility,  and  accountabili¬ 
ty.  Such  gaps  can  lead  to  miscommunica- 
tion  and  inefficiencies,  ultimately  detract¬ 
ing  from  the  group’s  ability  to  meet  its 
mission.  Power  distribution  is  not  always 
reflected  in  the  stated  organizational 
structure,  impacting  both  cohesiveness 
and  effectiveness. 

Many  change  efforts  acknowledge  the 
need  for  personal  empowerment  of  indi¬ 
viduals  and  work  teams,  but  unfortunately 
go  on  to  implement  structures  that  main¬ 
tain  the  status  quo  of  hierarchical,  top- 
down  flows  of  power  and  authority.  For 
example,  this  frequently  impacts  programs 
with  integrated  product  team  (IPT)  struc¬ 
tures.  Often,  IPTs  are  directed  to  make 
technical  decisions,  but  lack  the  authority 
to  implement  diem.  Structure  is  often  an 
issue  with  respect  to  stakeholder  manage¬ 
ment  as  well.  While  there  may  be  an  IPT 
responsible  for  user  requirements,  there 
may  be  few  structures  for  communicating 
dais  information  to  others,  resulting  in 
miscommunication  and  challenges  during 
implementation. 

Processes 

The  process  element  examines  how  work, 
people,  and  communication  are  organized 
and  acted  upon  to  accomplish  the  stated 
mission.  Are  teams  used  to  accomplishing 


die  mission?  What  is  the  strategy  used? 
What  is  the  role  of  technology  in  the 
group’s  efforts?  A  new  system  must  be 
accompanied  by  appropriate  policies  and 
procedures  -  the  processes  that  make  the 
technology  useable  and  ultimately  accept¬ 
ed  by  stakeholders,  including  die  users. 
Processes  that  fulfill  the  mission  efficient¬ 
ly  and  at  a  high  level  of  quality  are  work¬ 
ing  well,  while  processes  that  produce 
insufficient,  inferior,  or  untimely  products 
are  not. 

One  way  to  assess  process  effectiveness 
is  to  ask  team  members  about  the  program’s 
critical  path  and  how  they  contribute  to  it. 
How  does  what  they  are  working  on  sup¬ 
port  the  broader  goals?  Process  can  pose  a 
special  challenge,  for  example,  for  distrib¬ 
uted  teams  facing  die  dual  challenge  of 
completing  their  own  work  and  communi¬ 
cating  those  results  to  others.  While  policies 
and  procedures  are  an  important  tool  for 
managing  processes,  there  are  many  oilier 
pieces  to  this  puzzle  as  well. 

People 

Stakeholder  management,  interpersonal 
relationships,  role  clarity,  and  human 
resource  concerns  are  the  heart  of  die  peo¬ 
ple  dimension.  How  is  human  capital  lever¬ 
aged  for  die  greatest  organizational  effec¬ 
tiveness?  Organizations  are  human  systems, 
and  human  systems  function  best  when 
there  is  an  established  set  of  standards  to 
recruit,  train,  and  develop  people.  Also  crit¬ 
ical  to  the  people  component  of  the  model 
is  a  group’s  reward  system.  Change,  if  not 
success  in  general,  depends  on  people  feel¬ 


ing  both  accountable  and  empowered  to 
act,  to  decide,  to  suggest  -  at  times  even  to 
risk  failure.  Unfortunately,  people  often  find 
themselves  in  systems  that  talk  up  account¬ 
ability  and  risk,  but  reward  only  success.  A 
group’s  reward  structure  tells  a  lot  about 
what  a  culture  truly  values.  When  the  people 
in  an  organization  are  unrecognized,  unre¬ 
warded,  or  underdeveloped,  this  strand  of 
the  model  is  failing  and  the  organization 
suffers  as  a  result. 

Stakeholder  management  is  a  particu¬ 
larly  vital  aspect  of  the  people  element. 
Too  often,  programs  objectify  stakehold¬ 
ers  into  a  single  collection  of  interests 
without  acknowledging  the  variable  levels 
of  influence,  power,  and  need.  Failing  to 
overtly  delineate  the  differences  between 
primary  users,  secondary  users,  beneficiar¬ 
ies,  and  their  customers  can  cause  unantic¬ 
ipated  problems  during  deployment. 

Money 

Funding  usually  represents  a  defining  con¬ 
straint,  and  can  be  a  source  of  significant 
stress  and  conflict.  Such  conflicts  can  be 
serious  and  immediate,  as  financial  needs 
often  demand  attention  before  other 
issues.  What  many  fail  to  acknowledge, 
however,  is  that  funding  issues  often  signal 
deeper  concerns  related  to  stakeholder 
communication,  mission  clarity,  and 
requirements  creep. 

Unfortunately,  funding  problems  often 
spark  a  crisis  mentality,  aggravating  stress 
and  reducing  the  team’s  ability  to  consider 
both  strategic  and  tactical  options.  When 
money  is  compromised,  it  is  time  to  con- 
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sider  other  directions.  Sometimes,  budget 
allocations  can  be  changed,  but  when  they 
cannot,  taking  a  break  to  reconvene  a 
strategic  planning  process  may  prevent  a 
downward  spiral  from  which  the  program 
cannot  recover.  Therefore,  addressing 
connected  issues  in  mission,  leadership, 
and  structure  —  all  the  other  elements  of 
the  model  —  impacts  the  stress  and  limita¬ 
tions  of  financial  concerns. 

Environment 

An  organization’s  environment  is  the  col¬ 
lective  set  of  needs,  expectations,  and 
constraints  determined  by  external  factors 
(e.g.,  political  scrutiny,  operational  setting, 
and  technological  change).  If  a  program  is 
effectively  interacting  with  its  environ¬ 
ment,  then  program  boundaries  are  clear, 
external  dependencies  are  recognized,  and 
information  flows  both  inside  and  outside 
the  program. 

Interoperability  is  a  common  environ¬ 
mental  need.  With  increasing  emphasis  on 
systems  of  systems  and  interoperability, 
the  ability  to  talk  to  one  another  is  often 
critical.  Despite  dais  need,  programs  are 
often  relatively  autonomous,  with  pro¬ 
gram  managers  acting  with  independent 
authority.  While  dais  benefits  the  program 
itself,  it  can  lead  to  difficulties  in  other 
areas,  particularly  for  program  executive 
officers  and  enterprise-level  chief  infor¬ 
mation  officers  (CIOs).  These  are  envi¬ 
ronmental  complexities  that  are  revealed 
and  addressed  in  a  Wrapped  Cable  Model 
assessment. 

Culture 

Culture  emerges  from  all  the  other 


Wrapped  Cable  Model  elements  and 
results  in  a  set  of  commonly  held  rules, 
values,  expectations,  and  consequences 
that  shape  and  reflect  the  spirit  and  nature 
of  the  program  or  organization.  Culture, 
on  one  level,  is  the  sum  of  the  elements 
that  comprise  it  —  leadership,  structure, 
processes,  people,  and  money  -  all  acting 
in  the  environment  toward  a  mission.  At 
this  same  time,  however,  culture  is  a 
dynamic  all  its  own,  a  synergy  greater  than 
the  sum  of  its  parts.  So  while  the  elements 
of  a  system  act  on  culture,  culture  defines 
and  acts  on  these  elements  as  well.  This 
model  suggests  that  if  you  change  any  ele¬ 
ment  of  the  cable,  culture  will  also  change, 
but  as  the  model  also  shows  us,  the  pres¬ 
sure  of  the  culture  keeps  internal  forces  in 
the  model  tightly  in  place  and  static. 
Cultural  change  is  hard. 

Often,  compelling  pictures  of  culture 
comes  from  the  images  people  give  of 
their  teams.  On  a  recent  program  assess¬ 
ment,  one  team  we  interviewed  consistent¬ 
ly  used  images  of  forest  fires  to  describe 
their  operations;  another  team  generally 
reported  images  of  hectic  family  get- 
togethers  and  reunions.  Not  surprisingly, 
morale  differed  dramatically  between  these 
teams.  The  striking  point,  however,  is  that 
both  teams  were  part  of  the  same  program 
operating  in  different  locations,  providing 
a  unique  insight  into  the  tremendous  com¬ 
plexity  and  colliding  sub-cultures  of  large, 
distributed  programs. 

Intervention  Based  on  the 
Wrapped  Cable  Model 

So  far,  we  have  defined  the  model  ele¬ 


ments  and  illustrated  their  impact  in 
organizations  and  programs.  We  have 
come  to  regularly  use  the  model  as  part  of 
a  broader  assessment  and  development 
methodology  with  programs  and  teams 
seeking  both  to  solve  immediate  problems 
and  to  facilitate  long-term  cultural  change. 
Given  dais,  our  next  step  is  to  use  the 
Wrapped  Cable  Model  assessment  results 
to  design  and  implement  development 
activities.  The  Organization  Intervention 
Matrix  (Table  1)  shows  how  we  have 
mapped  some  of  the  common  DoD  chal¬ 
lenges  introduced  in  the  preceding  section 
against  the  model  elements.  The  last  col¬ 
umn  then  outlines  approaches  we  took  to 
address  these  issues  once  detected. 

The  following  bullets  describe  selected 
solutions/approaches  we  have  delivered  in 
more  depth.  In  each  case,  the  develop¬ 
ment  activity  is  designed  specifically  to  tar¬ 
get  the  issues  revealed  through  the 
Wrapped  Cable  Model  assessment. 

•  Strategic  planning  and  problem 
solving.  Structured  as  one-  or  two-day 
workshops  with  leadership  or  delivery 
teams,  these  sessions  are  used  to  iden¬ 
tify  how  the  organization’s  strengths 
can  be  used  to  overcome  weaknesses, 
leverage  opportunities,  and  mitigate 
risks  —  leading  to  specific  action  plans 
for  individual  and  team  implementa¬ 
tion.  Teams  can  often  use  this  forum 
to  identify  better  ways  to  communicate 
their  strengths,  both  within  and 
beyond  the  organization. 

•  Team  development  workshops. 
These  workshops  are  designed  to  pro¬ 
vide  leaders  and  teams  an  awareness  of 
their  personal  styles  and  how  these 
styles  both  contribute  to  and  inhibit 
team  success.  Personality  style  instru¬ 
ments  can  be  helpful  to  this  end;  the 
decision  of  which  instrument  to  use,  if 
any,  is  based  on  assessment  feedback. 
Participants  then  use  resulting  insights 
to  develop  both  personal  and  team 
action  plans  for  resolving  program 
challenges,  and  strategizing  how  best 
to  rally  around  and  contribute  to  the 
shared  mission. 

•  Team  training  workshops.  These 
sessions  provide  struggling  teams  with 
targeted  skills  training  or  development. 
This  includes  interpersonal  and  rela¬ 
tionship  management  skills  training  in 
active  listening,  communication,  con¬ 
flict  management,  negotiation,  meet¬ 
ing  management,  and/or  group  facili¬ 
tation  -  driven  again  by  assessment 
results. 

•  Leadership  development  training 
and  coaching.  Whether  a  group  train¬ 
ing  or  a  one-on-one  interaction 


Table  1 :  Organit^ation  Intervention  Matrix 


Challenge 

Mission 

Leadership 

Structure 

Processes 

People 

Money 

Environment  | 

Culture 

Solution  or  Approach 

Scope/Requirements 

Creep 

• 

o 

o 

o 

• 

o 

• 

Strategic  planning,  problem  solving,  and 
mission  realignment. 

Inadequate 

Stakeholder 

Management 

o 

o 

o 

• 

• 

Leadership  and  group  training,  including 
communication  and  feedback  to  end  users, 
sponsors,  stakeholder  groups,  and  oversight 
teams. 

Integrated  Product 

Team  Management 

o 

• 

o 

• 

• 

Organizational  structure  analysis  and  team 
facilitation,  development,  and/or  skills 
training. 

Interoperability 

Issues 

o 

o 

• 

o 

o 

o 

• 

• 

Strategic  planning,  organizational  structure 
analysis,  workgroup  facilitation,  and  team 
skills  training. 

Leadership 

Transitions 

• 

o 

o 

• 

• 

Leadership  training  and  coaching,  group 
training,  goal  refinement,  and  leader 
introduction  events. 

Distributed  Team 
Management 

o 

• 

• 

o 

o 

o 

• 

Leadership  training  and  coaching,  structure 
analysis,  team  development,  and  skills 
traininq. 

Technical  Innovation 
-  Difficulty  and  Risk 

• 

• 

o 

• 

o 

• 

o 

• 

Strategic  planning  and  problem  solving, 
leadership  development  and  coaching,  risk 
communication. 

•Signifies  points  of  primary  connection  or  concern  O  Signifies  points  of  secondary  connection  or  concern 
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Information  Technology  Policy  Team 

System  Development  Team 

Technical  Team 

Expressed 

Problem 

CIO  concerned  that  his  team  was 
responsible  for  a  wide  range  of 
initiatives  yet  was  failing  to 
communicate  activities  within  those  in 
related  areas  -  even  though  the  team 
works  in  the  same  office. 

System  team  in  requirements  phase 
encountered  diverse  and  conflicting 
needs  from  different  organizational 
leaders  -  with  no  clear  lead  system 
owner. 

Technical  team  implementing  a 
mandated  system  encountered  user 
resistance.  The  technical  team  was 
confused  by  this  resistance  given  the 
technology  improvements  offered  by 
the  new  system. 

Assessment  Finding 

•  M  and  L:  Staff  was  unclear  about 
mission  and  leader's  expectations. 

•  S:  Silos  lead  to  focus  on  individual 
performance,  inhibiting  cross 
communication. 

•  Pr  and  P:  Few  formal  team  meetings 
or  functions  and  a  lack  of  skill  or 
training  on  how  to  interact  with  and 
communicate  with  each  other. 

•  E:  Customers  confused  by 
inconsistent  communication  from 

CIO  team. 

The  team  was  missing  efficiencies  that 
could  be  gained  by  sharing  information, 
and  the  office  was  sending  mixed 
messages  to  customers.  Team 
reported  a  lack  of  clarity  in  expectations 
and  little  interaction  with  one  another. 

•  M  and  L:  Leaders  and  subordinates 
did  not  agree  on  scope,  focus,  and 
nuances  of  the  mission  and 

goals  -  and  who  should  have 
accountability  for  elements  of  the 
project. 

•  S:  Ambiguity  of  project  ownership 
reflected  in  organizational  chart. 

•  Pr  and  P:  Group  had  no  skill 
training  and  had  no  process  to  clarify 
or  communicate  their  confusion. 

Interview  results  and  project  artifacts 
signaled  a  lack  of  agreement  on 
program  mission  and  scope  from  the 
most  senior  levels  of  the  organization 
on  down. 

•  Pr:  Processes  were  not  in  place  to 
teach  and  ensure  user-centered 
customer  service. 

•  P:  Team  members  needed 
communication,  listening, 
customer  service  skills,  and 
incentives  that  rewarded  team 
members  for  using  those  skills 
effectively. 

•  E:  End  users  complained  about 
poor,  rude,  and  unhelpful  customer 
service. 

Technical  implementation  team  and 

Help  Desk  personnel  needed  better 
interpersonal  skills  for  empathizing  and 
supporting  user  groups  learning  the 
new  technology. 

(1)  Shift  emphasis  from  individual 

(1 )  Clarify  central  mission  and 

(1 )  Enhance  team's  ability  to  listen  and 

delivery  to  a  more  collaborative,  team- 

evaluation  criteria  for  system. 

empathize  with  user  concerns,  and 

C 

based  work  approach. 

(2)  Identify  a  clear  system  owner  with 

influence  user  acceptance  of  the  new 

<d 

(2)  Develop  and  implement  a  strategic 

authority  and  accountability  for 

mandated  tool. 

o  £ 

plan  to  identify  better  information 

decisions. 

(2)  Provide  technical  team  with  new 

o  o 

CD  (5 

sharing  processes  and  pathways. 

(3)  Reach  consensus  about  key 

techniques  for  responding  to  user 

> 

CD 

(3)  Take  a  time  out  from  focused 

system  capabilities,  decision  criteria, 

concerns. 

o 

delivery  to  spend  time  together  as  a 
team. 

and  program  rules  to  baseline 
requirements. 

Strategic  planning/team  building 

Facilitated  session  designed  and 

Personality-style  training  designed  and 

designed  and  delivered  that  did 

delivered  to  take  group  through  a 

delivered  to  the  group  that  resulted 

the  following: 

process  to  do  the  following: 

in  the  following: 

•  Facilitated  the  group's  membership 

•  Brainstormed  mission  and  evaluation 

•  Yielded  insight  into  the  learning, 

in  strategic  problem  solving,  focusing 

criteria. 

teaching,  and  communication  styles 

on  information  sharing  and 

•  Ranked  these  options. 

of  each  team  member. 

.C 

O 

establishing  communication 

•  Interactively  and  non-threateningly 

•  Enabled  group  to  anticipate  the 

ro 

o 

pathways  and  needed  outreach 

explored  priorities,  motives,  and 

styles  of  user  groups  and  how  best 

Q- 

activities  to  other  groups  and  projects. 

incentives  of  each  group. 

to  connect  to  these  customers  and 

< 

•  Administered  and  gave  interactive 

•  Creatively  problem-solved  these 

address  their  concerns. 

E 

feedback  on  a  personality  style  tool 

options  into  a  consensus  on  mission 

Technical  team  then  practiced  active 

2 

that  gave  team  members  insight  into 

that  suited  the  roles  and  structural 

listening  skills  and  brainstormed 

2 

the  benefits  and  liabilities  of  their 

limits  of  the  organization. 

reasons  for  user  resistance,  generating 

CL 

respective  communication  styles  - 

•  Concluded  with  all  members  writing 

sell  points  for  working  with  users. 

these  both  complement  and  struggle 

and  sharing  an  action  plan  that 

Facilitated  all  tsam  rriRmhors  to 

with  each  other  on  the  team  level. 

committed  them  to  specific  next 

write  and  share  an  action  plan  that 

•  Drove  all  members  to  write  and 
share  an  action  plan  that  committed 
them  to  specific  next  steps. 

steps. 

committed  them  to  next  steps. 

Note:  In  the  row  titled  Assessment  Finding  above,  M=Mission,  L=Leadership,  S=Structure,  Pr=Processes,  P=People,  and  E=Environment.  Culture  is  included  in  the  subtext 
of  every  element. 


Table  2:  Assessment  and  Development  Case  Studies 


between  a  program  leader  and  a  coach, 
these  efforts  are  designed  to  help  lead¬ 
ers  mobilize  their  powers  more  effec¬ 
tively  to  move  the  program  team  clos¬ 


er  to  its  mission  and  goals. 

Our  team  has  used  the  assessment  and 
development  approaches  described  above 
with  a  variety  of  technical  organizations 


and  programs,  ranging  from  senior 
ClO/policy  organizations,  to  program 
management  offices,  to  systems  develop¬ 
ment  teams.  The  matrix  in  Table  2  pro- 
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vides  three  examples  of  this  work  with 
reference  to  the  strands  of  the  model 
most  relevant  to  the  situation. 

Conclusion 

Changing  people  and  organizations  is 
hard.  Whether  you  are  working  with  a 
large  system  or  a  small  team,  the  challenge 
of  truly  developing  it  -  changing  it  -  is 
great.  Everything  is  interconnected,  so 
movement  anywhere  will  bring  about 
some  change  somewhere  else,  but  is  it  the 
change  you  wanted?  At  the  same  time,  the 
culture  of  a  system  —  just  like  the  casing  of 
a  wrapped  cable  -  is  such  that  there  is 
often  more  pressure  within  not  to  change 
regardless  of  your  efforts.  With  such 
dynamic  forces  facing  you,  where  do  you 
begin?  What  do  you  do?  The  Wrapped 
Cable  Model  is  not  offered  as  an  answer  to 
all  of  these  questions,  but  it  is  certainly  a 
starting  point  and  a  set  of  organizing  prin¬ 
ciples  and  questions  that  start  the  change 
and  development  process. 

Transforming  DoD  culture  requires 
first  identifying  and  then  developing  the 
critical  links  between  team  dynamics,  lead¬ 
ership  effectiveness,  and  program  perform¬ 
ance.  We  believe  that  the  greatest  success 
stories  in  changing  cultures  come  from 
enhanced  individual  self-awareness  and 
action  planning,  giving  individuals  the 
power  and  responsibility  to  create  positive 
and  actionable  change.  This  article  has 
described  a  method  for  starting  this 
process,  providing  a  way  to  break  down  cul¬ 
tural  transformation  into  the  daily  choices 
that  create  true  and  lasting  change.  ♦ 


Notes 

1 .  The  Wrapped  Cable  Model  is  the  intel¬ 
lectual  property  of  OKA  in  Fairfax, 
VA.  The  model  was  deployed  in  this 
team  dynamics  study,  and  is  the  under¬ 
pinning  model  of  the  case  studies 
herein.  For  more  information  on  the 
Wrapped  Cable  Model  or  any  other 


element  of  this  study  or  article,  con¬ 
tact  the  authors. 
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Commandments  for  a 
Productive  Development  Environment 
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The  software  development  industry  has  spent  decades  —  with  little  success  —  attempting  to  make  large  productivity  improve- 
ments  through  technology  changes.  Tut  some  projects  have  broken  the  productivity  barrier  by  applying  common  sense  practices 
to  the  people  side  of  the  development  process.  This  article  gives  a  set  of  commandments from  lessons  learned from  projects  with 
major  productivity  successes. 


For  more  than  40  years,  the  software 
development  industry  has  tried  to 
improve  productivity  by  implementing 
technology  advances  like  the  following: 

•  Third  and  fourth  generation  program¬ 
ming  languages. 

•  Structured  techniques  (functional  and 
object-oriented). 

•  Process  variations  (waterfall,  rapid 
application  development,  rapid  proto¬ 
typing). 

•  Environments  (programmer’s  work¬ 
bench,  .NET). 

•  End-user  programming. 

Some  technologies  have  worked  well. 
For  example,  the  introduction  of  higher 
order  languages  (FORTRAN,  etc.) 
reduced  the  size  of  software  programs  by 
as  much  as  70  percent.  Despite  this  gain, 
however,  if  we  measure  the  cost  of  devel¬ 
oping  a  single  source  line  of  code  from 
development  start  through  product  sell- 
off,  we  find  that  over  the  last  40  years  pro¬ 
ductivity  has  increased  an  average  of  only 
one  source  line  of  code  per  person-month 
per  year.  That  is,  the  average  productivity 
for  Department  of  Defense  software  has 
only  improved  from  about  60  lines  per 
person-month  in  1960  to  about  100  lines 
per  person-month  in  2000  for  similar 
products.  Thus,  we  see  technology 
advances,  including  structured  techniques, 
Computer  Aided  Software  Engineering 
(CASE)  tools,  modern  development  envi¬ 
ronments,  and  process  maturity  have  not 
provided  the  gains  we  anticipated. 

Figure  1  [1]  illustrates  the  vigor  with 
which  we  have  pursued  a  technology  solu¬ 
tion  (silver  bullet)  to  the  productivity 
problem.  The  key  to  increased  productivi¬ 
ty  must  therefore  be  elsewhere.  Weinberg 
demonstrates  this  by  comparing  the  rela¬ 
tive  percentages  of  Software  Engineering 
Institute  publications  in  major  activity 
areas  of  technology  (tools),  people  (edu¬ 
cation),  systems  (development  environ¬ 
ments),  and  management  to  the  relative 
productivity  gain  for  each  group. 
According  to  Weinberg,  the  most  signifi¬ 


cant  productivity  improvement  area  is,  by 
far,  the  manager  activity  area. 

Barry  Boehm  argues,  “Poor  manage¬ 
ment  can  increase  software  costs  more 
rapidly  than  any  other  factor.”  But  he 
explains  in  the  following: 

Despite  this  variation,  COCOMO 
[constructive  cost  model]  does  not 
include  a  factor  for  management 
quality,  but  instead  provides  esti¬ 
mates  which  assume  that  the  proj¬ 
ect  will  be  well  managed.  [2,  italics  per 
the  article  authors] 

Well  managed  does  not  work  in  this 
context.  Without  the  management  factors, 
we  cannot  distinguish  between  well-man- 
aged  and  poorly  managed  projects.  Looking 
at  the  results  from  the  2004  Standish  Chaos 
Report  [3],  most  projects  are  not  well  man¬ 
aged  today.  The  report  divides  projects  into 
three  classes:  successful,  challenged,  and 
failed.  About  28  percent  of  the  projects 
evaluated  were  classified  as  successful, 
albeit  they  delivered  an  average  of  only  52 
percent  of  the  original  requirements.  Fifty 
one  percent  were  delivered,  but  with  signif¬ 
icant  overrun  in  cost  and  schedule  while 
delivering  only  a  fraction  of  the  original 
requirements  (challenged).  About  18  per¬ 
cent  were  cancelled  before  delivery  (failed). 
In  other  words,  ignoring  management  fac¬ 
tors  in  an  estimating  tool  means  that  the 
projects  are  consistently  not  well  managed. 
All  projects  have  problems,  but  most  often 
they  are  people  problems  rather  than  tech¬ 
nological  problems. 

Recognizing  the  importance  of  good 
management  in  software  development 
productivity  is  only  the  first  step  in 
process  improvement.  Moreover,  good 
management  is  more  than  management 
style  and  organizational  ability.  Good 
management  requires  effective  communi¬ 
cation.  Effective  communication  is,  thus, 
essential  to  successful  software  develop¬ 
ment  productivity  gains. 

This  article  will  discuss  team  commu¬ 


nication  and  management  issues  within 
the  development  environment  and  their 
effect  on  software  productivity.  Solutions 
to  communication  problems  are  largely 
common  sense,  can  be  implemented  with 
minimal  investment,  and  have  almost 
immediate  payoffs. 

Over  years  of  observing  team  commu¬ 
nication  and  management  issues,  we  have 
found  four  practical  commandments  that 
profoundly  affect  productivity.  The  four 
commandments  deal  directly  with  commu¬ 
nication  and  collaboration  effectiveness. 
The  fourth  commandment  also  addresses 
motivational  and  team  issues,  as  well  as  a 
lack  of  continuity  when  members  of  the 
team  are  not  available  at  all  times.  Since 
effective  communication  is  the  backbone 
of  the  discussion,  we  begin  with  a  founda¬ 
tion  in  communication  mechanics. 


Mechanics  of  Communication 

Broadly  defined,  communication  means 
the  act  or  process  of  communicating,  and 
a  process  by  which  information  is 
exchanged  between  individuals  through  a 
common  system  of  symbols,  signs,  or 
behaviors.  A  related  definition  for  collab¬ 
oration  is  to  work  jointly  with  others  or 
together,  especially  in  an  intellectual 
endeavor.  Both  elements  are  necessary  to 
produce  a  software  product. 

Communication  or  information  trans- 
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fer  is  one  of  the  most  important  consider¬ 
ations  in  the  world  of  productivity 
improvement.  It  dominates  a  large  per¬ 
centage  of  the  time  devoted  to  software 
development  whether  information  is 
transferred  via  reports,  analysis,  problem 
resolution,  or  training.  Several  studies  sug¬ 
gest  the  time  spent  in  some  form  of  com¬ 
munication  exceeds  33  percent  of  a  pro¬ 
grammer’s  workday.  Improved  productivi¬ 
ty,  therefore,  relies  on  the  effective  and 
efficient  transfer  of  information. 

Information  Convection 

In  his  book  “Agile  Software  Develop¬ 
ment”  [4],  Alistair  Cockburn  described 
communication  by  comparing  it  to  the 
dispersion  of  heat  and  gas.  The  concept  is 
easy  to  apply  to  the  dynamics  of  commu¬ 
nication  in  the  software  development 
environment.  Convection  currents  of  infor¬ 
mation  move  about  a  work  area  just  like 
the  movement  or  dispersion  of  heat  and 
gas.  Air  moves  freely  through  an  area 
unless  the  air  is  blocked  or  diverted  by  an 
obstruction. 

Information  moves  in  precisely  the 
same  fashion.  When  two  programmers  are 
seated  at  adjacent  desks,  they  can  discuss 
mutual  problems  freely  and  information 
flows  unobstructed  between  the  two  peo¬ 
ple.  The  information  flow,  however, 
decreases  as  the  programmers’  separation 
distance  increases.  If  a  barrier  or  wall,  real 
or  perceived,  is  placed  between  the  pro¬ 
grammers,  the  information  flow  is  further 
attenuated  except  for  the  information  dis¬ 
persion  that  occurs  over  the  wall.  If  the 
programmers  are  placed  in  private  offices, 
the  information  flow  is  blocked  and 
becomes  zero.  Thus,  instead  of  a  commu¬ 
nicated  team  effort,  the  programmer’s  atti¬ 
tude  becomes,  “I  do  my  part  and  then 
throw  it  over  the  wall.” 


Figure  2:  Transfer  of  Information  in 
Presentations 
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Radiation 

Information  is  also  radiated.  Radiation  pri¬ 
marily  occurs  either  aurally  or  visually.  But 
it  can  also  occur  on  a  smaller  scale  from 
touch  and  smell.  Information  can  also  be 
radiated  from  whiteboards,  paper,  posters, 
sticky  notes,  and  pictures.  Because  we 
want  to  maximize  the  amount  of  useful 
information  being  conveyed,  we  will  dis¬ 
cuss  the  optimal  ways  that  information  is 
radiated. 

We  will  begin  with  close  proximity 
communication  and  discuss  the  radiation 
sources  one  at  a  time.  The  optimal  source 
of  radiation  communication  is  both  voice 
and  visual.  Voice  and  visual  communica¬ 
tion  is  radiated  by  expression,  gestures, 
pitch,  volume,  inflection,  exaggerations, 
and  movement.  Two  people  discussing  a 
problem  at  a  whiteboard  or  at  a  computer 
terminal  exemplify  this  ideal  situation.  This 
source  of  radiated  information  is  optimal 
because  of  the  response  time  between  the 
speaker’s  statements  and  the  listener’s 
responses.  The  real-time  nature  of  the  con¬ 
versation  allows  instantaneous  questions  to 
remove  any  misunderstandings  and  to  clar¬ 
ify  statements  and  questions. 

The  effectiveness  of  voice  or  visual 
radiation  is  supported  by  a  well-known 
research  study  by  Mehrabian  and  Ferris 
[5],  According  to  Mehrabian  and  Ferris,  55 
percent  of  information  in  presentations  is 
transferred  by  body  language,  i.e.,  posture, 
gestures,  and  eye  contact  (see  Figure  2). 
Thirty-eight  percent  of  the  information  is 
transferred  through  vocal  tonality,  i.e., 
pitch,  volume,  etc.  Seven  percent  of  the 
information  transferred  comes  from  the 
words,  or  content,  of  the  presentation. 
These  results  are  hardly  surprising  given 
that  our  body  cues  often  convey  the 
meaning  of  our  words.  For  example,  we 
all  express  many  shades  of  meaning  with 
the  word  no  in  normal  conversation  with¬ 
out  giving  much  thought  to  the  tone  and 
body  language  accompanying  the  word. 

The  effectiveness  of  the  information 
transfer,  however,  is  diminished  when  we 
remove  any  source  of  radiation.  For 
example,  we  can  remove  die  visual  part  of 
the  transfer  by  forcing  the  communicators 
to  use  a  telephone.  This  eliminates  all  of 
the  gestures,  body  language,  and  eye  con¬ 
tact  from  the  conversation.  These  impor¬ 
tant  radiation  sources  are  no  longer  avail¬ 
able  to  reinforce  understanding  between 
the  two  individuals,  and  can  lead  to  gaps  in 
communication  as  well  as  misunderstand¬ 
ings.  For  example,  we  may  change  our  lan¬ 
guage  style  when  talking  on  the  phone. 
This  could  lead  to  an  inference  of  disin¬ 
terest  that  seeing  body  language  would 


dispel.  People  cannot  see  you  nod  your 
head  in  agreement  on  the  telephone. 

The  information  transfer  is  further 
diminished  if  we  also  eliminate  the  subtle 
elements  of  a  conversation  radiated  by  vol¬ 
ume,  tone,  sarcasm,  or  disappointment  by 
using  e-mail  instead  of  the  vocal  conversa¬ 
tion.  Think  of  the  times  you  may  have 
called  or  been  called  by  someone  about  a 
date  or  an  appointment  and  they  made  an 
excuse  about  not  being  available.  The  loss 
of  vocal  tone  may  cause  you  to  miss  die  get 
lost  message  they  are  trying  to  convey. 

By  removing  all  radiating  sources  of 
information,  finally,  information  transfer  is 
significantly  degraded  when  we  remove  the 
ability  to  respond  and  ask  clarification 
questions  by  communicating  solely  on 
paper.  We  lose  not  only  the  subtle  elements 
of  our  voice  communication,  but  also  the 
real-time  element  of  the  conversation  nec¬ 
essary  for  feedback  from  one  to  another. 
Feedback  may  still  be  present,  but  at  a 
much  slower  rate.  This  impairs  the  integri¬ 
ty  or  accuracy  of  the  feedback  as  well. 

Paper  is  good  for  formality  and  struc¬ 
ture,  but  very  limiting  for  information 
transfer. 

Drafts 

In  the  convection  paradigm,  a  draft  is  a 
flow  of  unwanted  information. 

Ultimately,  information  flow  occurs 
whether  or  not  information  transfer  is 
desired.  Two  people  sitting  within  the 
range  of  a  radiator  pick  up  information 
even  when  they  are  not  directly  communi¬ 
cating.  The  receiver  can,  and  often  will, 
respond  to  the  radiator  if  the  information 
is  related  to  a  topic  of  interest.  Remember 
the  E.F.  Hutton  commercial?  When  die 
information  is  important  to  someone;  they 
listen.  The  receiver  may  also  respond  to  the 
radiator  if  the  information  is  disruptive. 
How  many  times  have  you  asked  someone 
to  turn  down  the  television  or  radio? 

Now  that  we  have  established  the 
communication  analogy,  let  us  look  at  the 
four  communication  commandments  for 
efficient,  effective  software  development. 

I.Thou  Shalt  Not  Construct 

Communication  Barriers 

As  explained,  walls  impede  the  flow  of 
information.  Consequently,  walls  decrease 
productivity.  This  impediment  includes 
both  visible  and  invisible  walls.  Private 
offices  and  cubicles  raise  visible  walls. 
Assume  a  large  open  area  filled  with  work¬ 
stations  that  are  spaced  10  feet  apart, 
front-to-back  and  side-to-side.  People  can 
move  freely  about  the  workspace.  Since 
they  are  not  totally  enclosed,  communica- 
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tion  between  individuals  in  this  matrix 
should  be  reasonably  unimpeded  [6],  This 
was  the  original  cubicle  concept. 

But  we  raise  invisible  walls  if  we  alter¬ 
nate  rows  in  this  matrix  with  personnel 
from  another  project.  This  spacing  causes 
die  distance  between  related  people  to 
increase  from  10  to  20  feet.  This  increased 
spacing  between  members  of  die  develop¬ 
ment  team  decreases  information  flow. 
Thus,  the  presence  of  unrelated  people 
forms  a  literal  wall  diat  impedes  die  infor¬ 
mation  flow.  The  same  effect  can  be 
achieved  by  randomly  placing  people  from 
a  second  project.  The  information  radiated 
by  people  from  the  unrelated  second  proj¬ 
ect  creates  what  Cockburn  referred  to  as  a 
draft  -  a  flow  of  unwanted  information. 

Invisible  walls  are  also  raised  by 
increasing  the  space  between  every  third 
row,  so  as  to  create  an  aisle  between  the 
rows.  Thus,  the  aisle  acts  as  a  barrier  or 
pseudo-wall.  The  aisle  significantly  in¬ 
hibits  die  flow  of  information  because 
people  are  naturally  resistant  to  communi¬ 
cation  across  assumed  walls. 

The  modern  technological  solution  to 
communication  barriers  is  e-mail  and  net¬ 
work  communications.  This  solution  has 
been  posed  for  local  communication  sup¬ 
port  and  to  justify  remote  software  devel¬ 
opment  teams.  Ironically,  this  technological 
solution  raises  greater  barriers  dian  the 
cubicle  example.  Where  people  have  at  least 
some  physical  contact  when  in  adjacent 
cubicles,  remote  locations  are  sometimes 
separated  by  a  diousand  miles.  The  loss  of 
visual  and  voice  radiation,  as  well  as  real¬ 
time  responsiveness  creates  a  virtual  wall. 

Skunk  Works 

A  classic  example  of  effective  information 
convection  is  the  Lockheed  Skunk  Works 
[7],  primarily  because  it  dispenses  with 
both  physical  and  non-physical  walls.  The 
most  successful  software  organizations 
have  followed  this  paradigm  in  the  organ¬ 
ization  of  their  development  teams  and 
environments. 

The  Skunk  Works  is  an  unofficial 
name  given  to  the  Lockheed  Advanced 
Development  Projects  Unit,  which  was 
die  home  of  the  legendary  Kelly  Johnson 
and  his  production  team.  In  makeshift 
quarters,  Johnson’s  team  developed  the 
U.S.  Air  Force’s  first  operational  jet  fight¬ 
er,  die  P-80  Shooting  Star ,  in  only  143  days. 
Since  then,  a  number  of  famous  aircraft, 
including  the  U-2,  the  SR-71,  and  the  F- 
117  have  been  developed  by  this  produc¬ 
tion  unit.  The  newest  Skunk  Works  proj¬ 
ect  is  the  F-35  Joint  Strike  Fighter. 

As  a  generic  term,  skunk  works  dates 
back  to  the  1960s.  The  common  skunk 


works  definition  is  a  small  group  of 
experts  who  move  outside  an  organiza¬ 
tion’s  mainstream  operations  to  develop  a 
new  technology  or  application  as  quickly 
as  possible,  without  the  burden  of  the 
organization’s  bureaucracy  or  strict 
process  application.  Conventional  skunk 
works  operations  are  characterized  by 
people  who  are  free  thinkers,  creative,  and 
who  do  not  let  conventional  boundaries 
get  in  the  way.  The  skunk  works  work¬ 
space  is  a  physically  open  environment 
that  encourages  intra-team  access  and 
communication.  Tools  and  processes  are 
tailored  and  adapted  to  the  project’s 
requirements.  Johnson  established  14 
Basic  Operating  Rules  [7]  to  minimize 
development  risk  while  maintaining  the 
greatest  possible  agility  and  creativity  in  a 
lean  development  team.  The  rules  covered 
everything  from  program  management  to 
compensation,  and  are  relevant  for  any 
advanced  research  unit  within  a  larger 
organization. 

The  management  and  teaming  charac¬ 
teristics  of  the  skunk  works  are  important 
to  our  discussion  of  die  commandments 
for  a  productive  development  organization 
primarily  because  they  removed  the  walls 
or  barriers  diat  hamper  communication. 

Cube  Farm 

A  counter-example  to  die  skunk  works 
approach  to  software  development  is  the 
common  cube  farm.  The  cube  farm  vio¬ 
lates  all  the  rules  for  a  productive  environ¬ 
ment  in  terms  of  bodi  communication 
and  collaboration  primarily  because  they 
raise  all  the  barriers  that  block  communi¬ 
cation.  Unfortunately,  the  cube  farm  is  the 
most  common  or  widely  used  software 
development  environment.  Probably  90 
percent  to  95  percent  of  the  development 
organizations  operating  today  work  in 
cube  farms.  A  common  programmer 
response  when  asked  about  dieir  work¬ 
space  is,  “Scott  Adams  used  our  organiza¬ 
tion  as  the  pattern  for  Dilbert.”  Many 
diink  Scott  Adams  is  an  alias  for  one  of 
dieir  employees. 

In  fact,  die  evolution  of  the  cube 
farm,  a  grouping  of  cubicles  that  opti¬ 
mizes  the  number  of  people  per  square 
foot  of  floor  space,  did  not  begin  as 
depicted  in  the  Dilbert  cartoons.  In  the 
late  1950s,  typical  offices  were  large  open 
spaces  filled  with  orderly  rows  of  desks, 
and  surrounded  by  private,  closed  offices 
for  supervisory  personnel.  At  about  the 
same  time,  the  Henry  Miller  Company 
approached  Robert  Probst  [8],  a  professor 
of  fine  arts  at  the  University  of  Colorado, 
to  create  a  furniture  design  that  would 
improve  communication  and  productivity. 


The  result,  die  Henry  Miller  Action  Office 
system,  appeared  in  the  mid-60s.  The 
approach  started  with  a  large  open  area, 
sectioned  to  give  workers  semi-private  to 
private  enclosed  spaces  where  needed,  but 
the  work  area  was  arranged  in  a  way  to 
provide  ease  of  worker-to-worker  and 
worker-to-manager  interaction.  The 
design  promoted  communal  space  for 
interaction.  The  Action  Office  was  an 
immediate  success. 

Enter  now  the  facilities  planner  or  space 
police.  Their  plan  was  to  remove  all  of  the 
wasted  open  space  to  maximize  die  use  of 
a  building’s  floor  space.  Or,  in  other 
words,  maximize  die  number  of  people 
per  power  oudet.  The  resulting  cube  farm 
does  just  that  by  providing  high  human 
density,  easy  reconfiguration,  and  facility 
cost  savings.  But  the  saved  space  is  more 
than  counteracted  by  the  resulting  high 
price  in  loss  of  product  development  effi¬ 
ciency  and  productivity.  Thus,  decisions 
by  facility  planners  have  dramatically 
affected  project  schedules. 

This  is  because  the  cube  farm,  as  it 
exists  today,  virtually  eliminates  informa¬ 
tion  convection  by  blocking  all,  or  essen¬ 
tially  all,  personal  interactions.  The  stan¬ 
dard  six-foot  by  eight-foot  sound  insulat¬ 
ed  cubicle  lacks  space  for  a  two-person 
discussion,  contains  no  whiteboards  or 
other  communication  media,  and  pipes 
drafts  (white  noise)  into  the  farm  back¬ 
ground  to  suppress  any  information  diat 
might  escape  into  the  environment.  In 
short,  the  cube  farm  is  the  least  likely  of 
all  facility  arrangements  to  encourage 
improvements  in  productivity. 

II. Thou  Shalt  Dedicate  the 
Project  Area 

The  physical  project  area  should  be  allo¬ 
cated  to  a  specific  development  task  and 
not  shared  by  multiple  projects.  From  the 
standpoint  of  information  convection,  all 
of  the  information  moving  about  the 
development  area  should  be  related  to  the 
same  software  development  activity. 
Mixing  projects  in  a  specified  area  creates 
drafts.  The  drafts  are  created  by  mixing 
people  from  unrelated  tasks.  Dedicating  a 
specific  project  area  places  all  of  the 
development  personnel  in  close  proximity 
widi  as  few  sources  for  drafts  as  possible. 
Adding  people  from  non-related  projects 
also  separates  project-related  people, 
thereby  limiting  the  information  flow  and 
inhibiting  discussion  and  collaboration. 

Anodier  side  effect  of  an  undedicated 
project  area  is  that  die  presence  of  people 
from  another  task  prevents  the  team  from 
forming  into  a  focused,  cohesive  unit.  An 
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extreme  view  of  this  phenomenon  occurs 
when  the  project  area  is  a  general  software 
engineering  area  accommodating  multiple 
projects.  Project  teams  never  form  in  this 
situation. 

Several  years  ago,  a  software  team  car¬ 
ried  the  dedicated  workspace  concept  to  a 
new  level.  The  manager  physically  moved 
die  team  to  an  unused  cafeteria.  Widi 
soap,  water,  and  the  support  of  Canteen 
Corp.  (the  vending  machine  supplier),  the 
team  created  a  project  area  remote  from 
outside  interference.  The  members  were 
experienced,  but  not  individual  superstars. 
The  team  evaluation  at  project  completion 
received  die  highest  performance  rating 
(aka,  Seer  [9]  basic  technology  constant) 
recorded  at  the  time. 

A  corollary  to  the  second  command¬ 
ment  is  that  outsiders  should  not  mess  widi 
die  project  area.  The  project  area  needs  to 
be  die  project  domain,  controlled  by  the 
project  team. 

III. Thou  Shalt  Provide 
Utensils  for  Creative  Work 

When  we  consider  tools  for  creative  work, 
we  usually  think  of  the  technology  bucket. 
Technology-oriented  tools  include  pro¬ 
gramming  languages,  computer  systems, 
development  environments,  CASE  and 
scheduling  tools,  and  formal  practices  and 
procedures.  All  of  these  technology  tools 
affect  productivity,  but,  as  stated,  this 
impact  is  minor  compared  to  the  produc¬ 
tivity  impact  of  poor  communication. 

We  have  learned  from  experience  and 
research  that  communication  and  collab¬ 
oration  are  key  to  productivity  and  quali¬ 
ty  improvement.  Our  earlier  discussion 
about  information  convection  and  radia¬ 
tion  suggests  that  a  completely  different 
set  of  low-tech  utensils  are  best  for  cre¬ 
ative  work.  These  utensils  include  the  fol¬ 
lowing: 

•  Whiteboards. 

•  Easel  pads. 

•  Butcher  paper. 

•  Post-it  Notes. 

•  Kitchenette  (break  room  with  white¬ 
boards). 

•  Informal  discussion  areas  (brainstorm¬ 
ing  area). 

•  Popcorn. 

None  of  these  utensils  fit  well  within  a 
cubicle  environment.  Whiteboards,  Post-it 
Notes,  and  popcorn  can  be  physically 
placed  in  a  cubicle,  but  for  individual  use 
only.  Group  activities  using  the  above 
utensils  require  large  cubicles  that  support 
teams  rather  then  separate  diem.  The 
space  police  look  at  team  space  as  wasted 
and  diey  want  to  pack  more  individual 


bodies  into  diat  space.  But,  the  environ¬ 
ment  we  want  to  foster  is  people  working 
together  effectively.  Effective  team  activi¬ 
ties  require  utensils  to  support  communi¬ 
cation.  You  cannot  tell  a  child  not  to  eat 
with  his  or  her  hands  without  providing  an 
alternative.  Likewise  you  cannot  build 
project  teams  without  providing  team¬ 
building  tools. 

When  evaluating  an  organization’s  pro¬ 
ductivity,  the  presence  or  absence  of  diese 
tools  profoundly  affects  die  result.  Popcorn 
may  seem  like  a  strange  tool,  but  it  is  almost 
always  present  in  a  highly  productive  work 
area.  While  popcorn  does  not  analytically  fit 
into  any  criteria  for  improved  productivity, 
its  odor  seems  to  attract  die  necessary  col¬ 
laboration  and  enhanced  communication. 
The  scent  of  popcorn  is  indicative  of  peo¬ 
ple  working  together. 

IV.Thou  Shalt  Not  Share 
Resources 

People-sharing  between  projects  makes  it 
impossible  to  form  a  genuine  development 
team  for  any  specific  task.  Part-time  com¬ 
mitment  does  not  permit  shared  individu¬ 
als  to  fully  participate  in  a  task.  This  ulti¬ 
mately  limits  support  physically  as  well  as 
socially.  Teams  are  sensitive  to  part-time 
participation.  The  part-time  individual  is,  in 
a  sense,  an  outsider  and  will  not  be  trusted 
to  carry  out  a  task  if  not  fully  committed. 
Teams  cannot  gel  when  full-time  participa¬ 
tion  in  the  project  is  not  die  norm. 

Another  phenomenon  occurs  when 
people  are  shared  between  two  or  more 
projects.  Information  that  relates  to  one 
project  becomes  a  draft  for  resources  par¬ 
ticipating  in  a  second  project.  Thus,  when 
more  than  one  project  is  active  in  a  given 
area,  the  need  for  individual  privacy 
becomes  an  issue  due  to  the  distracting 
information  flow  or  noise  in  die  area. 

Food  for  Thought 

Communication  and  collaboration  are 
vital  elements  of  die  software  develop¬ 
ment  activity.  When  we  accept  this  as  a 
truth,  we  recognize  die  importance  of 
making  communication  effectiveness  a 
priority  in  project  planning. 

There  are  some  important  issues  relat¬ 
ed  to  the  success  of  environments  associ¬ 
ated  with  die  four  development  environ¬ 
ment  commandments  described  in  diis 
article.  The  issues  are  the  following: 

1.  The  software  development  industry 
has  pursued  many  technology 
approaches  for  improved  productivity 
over  the  past  40  years.  Communica¬ 
tions  and  collaboration  issues  cannot 
be  resolved  widi  the  next  silver  bullet 


(new  technology  tool) . 

2.  Management  culture  changes  slowly,  if 
at  all.  (We  learn  from  experience  that 
we  do  not  learn  from  experience.) 

3.  Most  managers  are  not  brave  enough 
to  keep  their  hands  off,  to  accept  diat 
a  major  part  of  their  business  will  be 
performed  by  a  remote  operation  that 
they  cannot  interfere  with.  A  large  part 
of  Lockheed’s  management  resented 
the  existence  of  the  skunk  works  and 
its  success. 

4.  Low  team-staffing  levels  and  efficient 
(highly  productive)  operations  equate 
to  low  profits  on  traditional  govern¬ 
ment  contracts,  which  reward  effort 
rather  than  results. 

5.  Small,  highly  cohesive  teams  having  lit¬ 
tle  interaction  with  die  larger  organiza¬ 
tion  equates  to  litde  opportunity  for 
raises  and  promotions,  especially  in  a 
traditional  organization  that  wants  to 
reward  managers  based  on  die  number 
of  people  supervised  radier  than  on 
results. 

6.  The  skunk  works  model,  where  die 
skunk  works  has  considerable  freedom 
to  innovate  and  arrive  at  its  own  solu¬ 
tion  to  the  customer’s  problems,  does 
not  work  well  widi  customers  or  man¬ 
agers  who  want  total  control.  The 
skunk  works  gives  die  team  the  power 
to  create,  communicate,  and  overcome 
challenges  without  micro-management. 
There  are  management  ideas  to  help 

enable  the  team  communication  and  the 
project  to  succeed.  Management  style  is 
inherendy  important  in  this  promotion  of 
team  development  by  enhancing  commu¬ 
nication.  The  following  summarizes  this: 

1.  Management  cannot  be  a  bottleneck 
of  communication.  Management  must 
allow  die  team  to  contact  the  necessary 
people  both  inside  and  outside  the 
team  to  get  the  needed  information. 

2.  Teams  are  not  just  created;  they  grow 
through  communication,  interaction, 
and  trust.  Management  must  recognize 
this  and  try  to  create  not  only  mem¬ 
bership  in  a  team  but  an  environment 
conducive  to  communication  and 
interaction.  After  the  membership  and 
environment  are  in  place,  the  trust 
grows.  As  part  of  the  trust  environ¬ 
ment,  team  members  need  to  feel  that 
sharing  information  with  others  does 
not  threaten  their  individual  job  status, 
ability  to  advance,  or  bonuses. 

3.  Managers,  customers,  and  teams  need 
an  atmosphere  of  trust  and  accounta¬ 
bility. 

4.  Management  needs  to  view  itself  as 
support  personnel  that  enable  the 
team  to  succeed  and  not  as  the  dictat- 
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ing,  governing  body.^ 
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Who’s  on  Project  Management? 


Writing  on  the  eve  of  the  World  Series,  what  better  way  to 
spur  thought  on  communication  than  to  have  Abbott  and 
Costello  throw  out  the  first  pitch? 

Costello:  Abbott,  if  we  are  going  to  develop  quality  software,  we 
need  to  know  the  development  team. 

Abbott:  We  certainly  do.  Who  is  the  project  manager,  What  is 
the  designer,  I  Don’t  Know  is  the  programmer... 

Costello:  That  is  what  I  want  to  find  out. 

Abbott:  Yes,  Who  is  the  project  manager,  What  is  the  designer,  I 
Don’t  Know  is  the  programmer... 

Costello:  They  are  our  development  team  and  you  don’t  know 
their  names? 

Abbott:  Well  I  should. 

Costello:  Well  then,  who  is  the  project  manager? 

Abbott:  Yes. 

Costello:  The  project  manager’s  name? 

Abbott:  Who. 

Costello:  The  woman  managing... 

Abbott:  Who  is  managing  the  project! 

Costello:  I’m  asking  you,  who  is  managing  the  project? 

Abbott:  That’s  the  woman’s  name. 

Costello:  That’s  whose  name? 

Abbott:  Yes. 

Costello:  All  I’m  trying  to  find  out  is  what  the  woman’s  name  is 
managing  the  project. 

Abbott:  No,  What  is  the  designer. 

Costello:  I’m  not  asking  about  design. 

Abbott:  Well,  don’t  change  the  team. 

Costello:  I’m  not  changing  anybody!  I  am  only  asking  you,  who 
is  the  woman  managing  the  project? 

Abbott:  That’s  right. 

Costello:  What’s  the  woman’s  name  managing  the  project? 
Abbott:  No,  What  is  the  designer. 

Costello:  I’m  not  asking  you  who  is  designing  the  software. 
Abbott:  Who  is  managing  the  project. 

Costello:  I  don’t  know. 

Abbott:  He’s  the  programmer. 

Costello:  Now  how  did  we  get  on  the  programmer? 

Abbott:  You  mentioned  his  name. 

Costello:  If  I  mentioned  his  name,  who  did  I  say  is  program¬ 
ming? 

Abbott:  No,  Who’s  managing  the  project. 

Costello:  What’s  managing  the  project? 

Abbott:  What’s  designing  software. 

Costello:  I  don’t  know. 

Abbott:  He’s  programming. 

Costello:  Look,  do  you  have  an  SEPG? 

Abbott:  Sure. 

Costello:  The  SEPG  Leader’s  name? 

Abbott:  Why. 

Costello:  I  just  thought  I’d  ask. 

Abbott:  Well,  I  just  thought  I’d  tell. 

Costello:  Then  tell  me  who  leads  the  SEPG. 


Abbott:  Who’s  managing  the  project;  she  can’t  do  both. 
Costello:  Stay  out  of  management!  I  want  to  know  what’s  the 
person’s  name  leading  the  SEPG? 

Abbott:  No,  What  is  designing  software. 

Costello:  I’m  not  asking  you  who’s  designing  the  software. 
Abbott:  Who’s  managing  the  project! 

Costello:  I  don’t  know. 

Together:  Programming! 

Costello:  Look,  do  you  have  a  configuration  manager  on  this 
team? 

Abbott:  Sure. 

Costello:  The  configuration  manager’s  name? 

Abbott:  Tomorrow. 

Costello:  You  won’t  tell  me  today? 

Abbott:  I’m  telling  you  now. 

Costello:  Then  go  ahead. 

Abbott:  Tomorrow! 

Costello:  What  time  tomorrow  are  you  telling  me  who’s  manag¬ 
ing  the  software  configuration? 

Abbott:  Who  is  not  managing  the  software  configuration.  She  is 
managing  the  project. 

Costello:  I’ll  break  your  arm  if  you  say  who’s  managing  the  proj¬ 
ect  one  more  time!  I  want  to  know  what’s  the  configuration  man¬ 
ager’s  name? 

Abbott:  What’s  designing  software. 

Costello:  I  don’t  know. 

Together:  Programming! 

Costello:  Do  you  have  a  customer  rep? 

Abbott:  Certainly. 

Costello:  The  rep’s  name? 

Abbott:  Today. 

Costello:  So  an  ornery  customer  throws  a  curveball  requirement 
at  me.  I  pick  up  the  requirement  and  take  it  to  who? 

Abbott:  Now  that’s  the  first  tiling  you’ve  said  right. 

Costello:  I  don’t  even  know  what  I  said! 

Costello:  I  take  die  requirement  to  Who.  Who  picks  up  the 
requirement  and  gives  it  to  What.  What  gives  design  require¬ 
ments  to  I  Don’t  Know.  I  Don’t  Know  notifies  Tomorrow  of  the 
change.  Another  customer  gets  up  and  gives  Today  a  require¬ 
ment.  Why?  I  don’t  know!  He’s  programming  and  I  don’t  give 
a  darn! 

Abbott:  Oh,  that’s  our  test  engineer. 

Developing  software  can  be  complicated  but  you  can’t  get  to 
first  base  without  good  communication. 

Who’s  your  Project  Manager?  I  hope  it’s  not  I  Don’t  Know 
or  I  Don’t  Give  a  Darn. 

—  Gary  A.  Petersen 

Shim  Enterprise,  Inc. 
gary.petersen@shiminc.com 
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